Junio C Hamano:
as merely a different way to do the following:
$ git commit -m A
$ edit
$ edit further ;# working tree has an equivalent of C
$ git commit --amend -a
Indeed. My last command in the chain is usually
git commit --amend --date=now
to set the co
Jeff King writes:
> Yes, 2^31-1 is probably a better number, but it's harder to write out. :)
>
> Here's what a patch might look like to implement "0". By still using
> xargs in the unlimited code path, it's not too bad. I dunno.
As somebody who is too used to run "diff -U999" and be happy, I
Emily Shaffer writes:
> Then, figuring that I only had a few files, I thought I'd type them
> each, with the exception of a .c/.h pair:
>
> g restore --staged builtin/log.c builtin/walken.c revision.*
>
> Because I had build artifacts present, this vomited while trying to
> unstage revision.o, an
Stephen Boyd writes:
> I wonder if we need to make some other sort of form of
> "prerequisite-patch-id:" here and let that be a legacy form of the
> patch-id so that users know that they have a fixed version of this code?
> Maybe "prerequisite-stable-patch-id:"? Or we don't have to care because
>
Denton Liu writes:
> In git-format-patch, notes can be appended with the `--notes` option.
> However, this must be specified by the user on an
> invocation-by-invocation basis. If a user is not careful, it's possible
> that they may forget to include it and generate a patch series without
> notes
Peter Krefting writes:
> Junio C Hamano:
>
>>> Using interactive rebase has one flaw IMHO and that is the way it
>>> handles dating its commit. Can you add an option to interactive rebase
>>> that would make it use the date from the commit that is most recent
>>> and not the date from the commit
I know these can take some time but is this pending any update from
me? The accepted changes will be merged back into the diff-so-fancy
project.
There was a question about other uses of /dev/null. In the contrib
directory, there are a couple of uses.
contrib/buildsystems/engine.pl - not clear i
Nguyễn Thái Ngọc Duy writes:
> But due to the way the options parsing machinery works this resulted
> in the rather absurd situation of:
>
> $ git clone --recurs [...]
> error: ambiguous option: recurs (could be --recursive or
> --recurse-submodules)
>
> Add OPT_ALIAS() to express this
On Mon, May 6, 2019 at 7:55 PM Jeff King wrote:
> Here's what a patch might look like to implement "0". By still using
> xargs in the unlimited code path, it's not too bad. I dunno.
>
> ---
> diff --git a/Makefile b/Makefile
> index daba958b8f..0765a59b7a 100644
> --- a/Makefile
> +++ b/Makefile
>
On Tue, May 07, 2019 at 11:42:28AM +0900, Junio C Hamano wrote:
> > Making "0" work as "unlimited" might be nice, but xargs doesn't support
> > that and I didn't want to make the recipe any more unreadable than it
> > already is.
>
> Sounds good. After reading the log message, I was curious if t
Jeff King writes:
> The implementation is done with xargs, which should be widely available;
> it's in POSIX, we rely on it already in the test suite. And "coccicheck"
> is really a developer-only tool anyway, so it's not a big deal if
> obscure systems can't run it.
OK.
> I left the default at
Duy Nguyen writes:
> On Thu, Apr 25, 2019 at 8:15 PM Junio C Hamano wrote:
>> * nd/config-move-to (2019-01-14) 7 commits
>> - config.h: fix hdr-check warnings
>> - config: add --move-to
>> - config: factor out set_config_source_file()
>> - config: use OPT_FILENAME()
>> - config.c: add repo_
Hiya,
On Thu, Apr 25, 2019 at 04:45:44PM +0700, Nguyễn Thái Ngọc Duy wrote:
> v3 changes are really small
>
> - gitcli.txt is updated to mention the --staged/--worktree pair, in
> comparison to --cached/--index which is also mention there.
>
> - The patch 'rm --staged' is dropped. It could com
On Mon, May 06, 2019 at 06:41:03PM -0700, Jacob Keller wrote:
> > So here's what I think we should apply:
> >
> > -- >8 --
> > Subject: [PATCH] coccicheck: optionally batch spatch invocations
> [...]
>
> This looks reasonable to me :)
Thanks. I should have added a:
Based-on-a-patch-by: Jacob
On 5/6/2019 5:58 PM, Emily Shaffer wrote:
> Hi,
>
> This change looks good to me, and like good evidence for the benefits of
> automated tooling :)
Same here! Keep up the great work here.
-Stolee
On Mon, May 6, 2019 at 4:43 PM Jeff King wrote:
>
> On Mon, May 06, 2019 at 04:34:09PM +0700, Duy Nguyen wrote:
>
> > > However, it comes at a cost. The RSS of each spatch process goes from
> > > ~50MB to ~1500MB (and peak memory usage may be even higher if make runs
> >
> > 1.5G should be fine. T
Jeff Hostetler writes:
> I forgot to update the cover letter for V5.
> V5 adds a commit to fix the permission problem in /etc/gitconfig
> reported by SZEDER.
>
> This commit could/should be squashed into commit 5 if wanted.
> I left it on top for review purposes.
I think v4 has been in 'next' fo
Matthew DeVore wrote:
> On 2019/05/06, at 12:46, Jonathan Nieder wrote:
>> Ah, interesting. When this was discussed before, the proposal has been
>> that the client can say "have" anyway. They don't have the commit and
>> all referenced objects, but they have the commit and a *promise* that
>>
On Пн, May 6, 2019 at 18:25, Eric Sunshine
wrote:
On Mon, May 6, 2019 at 4:30 PM Emily Shaffer
wrote:
On Fri, May 03, 2019 at 06:04:15PM +0300, Konstantin Kharlamov
wrote:
> Interactive rebase (i.e. for example "git rebase -i HEAD~10") is
used most
> often to apply an action to a singl
On Mon, May 06 2019, Robert Dailey wrote:
> I feel like you got hung up too much on exact wording of what I was
> trying to describe. I do apologize I don't have the background to
> explain things 100% accurately, especially at a low level. My
> explanations are mostly intended to be as a user,
On Mon, May 06, 2019 at 04:34:09PM +0700, Duy Nguyen wrote:
> > However, it comes at a cost. The RSS of each spatch process goes from
> > ~50MB to ~1500MB (and peak memory usage may be even higher if make runs
>
> 1.5G should be fine. Trying...
>
> Even with no -j, my htop's RES column goes up 6
> On 2019/05/06, at 12:46, Jonathan Nieder wrote:
>
> Hi,
>
> Jonathan Tan wrote:
>> Matthew DeVore wrote:
>
>>> I'm considering implementing a feature in the Git protocol which would
>>> enable efficient and accurate object negotiation when the client is a
>>> partial clone. I'd like to ref
On Mon, May 06 2019, Palauzov, Dilyan wrote:
> I added manually a remote to .git/config, but updated only the url= line,
> forgetting to update the fetch= line. So two
> remotes had
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> and fetching from the one or the other has overwritten origi
Follow-up my preceding change which fixed the immediate "./run
" regression in 0baf78e7bc ("perf-lib.sh: rely on
test-lib.sh for --tee handling", 2019-03-15) and entirely get rid of
GIT_TEST_INSTALLED from perf-lib.sh (and aggregate.perl).
As noted in that change the dance we're doing with GIT_TES
Fix a really bad regression in 0baf78e7bc ("perf-lib.sh: rely on
test-lib.sh for --tee handling", 2019-03-15). Since that change all
runs of different of git have used the git found in the
user's $PATH, e.g. /usr/bin/git instead of the we just
built and wanted to performance test.
The problem st
On Mon, May 06 2019, Jeff King wrote:
> On Mon, May 06, 2019 at 09:16:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> Perhaps there's some better way to fix this, but it seems to me that
>> the best solution is to just make this behavior less magical. We know
>> in run_dirs_helper() that we're abo
On Mon, May 6, 2019 at 12:28 PM Jonathan Tan wrote:
>
> > I'm considering implementing a feature in the Git protocol which would
> > enable efficient and accurate object negotiation when the client is a
> > partial clone. I'd like to refine and get some validation of my
> > approach before I start
Sorry for not looking at this sooner.
Firstly, I'm not sure if this file should be named without the ".txt",
like SubmittingPatches.
As for my other comments below, the Makefile comment below is the only
one I feel strongly about; feel free to disagree with the rest (which I
think are subjective
On Mon, May 6, 2019 at 4:30 PM Emily Shaffer wrote:
> On Fri, May 03, 2019 at 06:04:15PM +0300, Konstantin Kharlamov wrote:
> > Interactive rebase (i.e. for example "git rebase -i HEAD~10") is used most
> > often to apply an action to a single commit, e.g. "rename", "edit", "fixup",
> > etc…
> >
>
Hi,
This change looks good to me, and like good evidence for the benefits of
automated tooling :)
Thanks!
- Emily
On Mon, May 06, 2019 at 02:36:58PM -0700, Josh Steadmon wrote:
> Free the commit graph when verify_commit_graph_lite() reports an error.
> Credit to OSS-Fuzz for finding this leak.
Free the commit graph when verify_commit_graph_lite() reports an error.
Credit to OSS-Fuzz for finding this leak.
Signed-off-by: Josh Steadmon
---
commit-graph.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/commit-graph.c b/commit-graph.c
index 66865acbd7..4bce70d35c 10
Hi,
On Fri, May 03, 2019 at 06:04:15PM +0300, Konstantin Kharlamov wrote:
> Interactive rebase (i.e. for example "git rebase -i HEAD~10") is used most
> often to apply an action to a single commit, e.g. "rename", "edit", "fixup",
> etc…
>
> As result, people keep coming up with custom scripts and
On Mon, May 06, 2019 at 09:16:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Perhaps there's some better way to fix this, but it seems to me that
> the best solution is to just make this behavior less magical. We know
> in run_dirs_helper() that we're about to run performance tests on a
> given , so
Hi,
Jonathan Tan wrote:
> Matthew DeVore wrote:
>> I'm considering implementing a feature in the Git protocol which would
>> enable efficient and accurate object negotiation when the client is a
>> partial clone. I'd like to refine and get some validation of my
>> approach before I start to write
> I'm considering implementing a feature in the Git protocol which would
> enable efficient and accurate object negotiation when the client is a
> partial clone. I'd like to refine and get some validation of my
> approach before I start to write any code, so I've written a proposal
> for anyone int
> There has been no answer to my comments in:
>
> https://public-inbox.org/git/CAP8UFD3SWNu=btPxV2vV=neyrofbgkpzz_wlvsjbv6bkjro...@mail.gmail.com/
>
> especially the part related to the "-o avoid-cdn=badcdn.example.com"
> example that Jonathan Nieder gave.
It seems to me that if you use a server
Fix a really bad regression in 0baf78e7bc ("perf-lib.sh: rely on
test-lib.sh for --tee handling", 2019-03-15). Since that change all
runs of different of git have used the git found in the
user's $PATH, e.g. /usr/bin/git instead of the we just
built and wanted to performance test.
The problem st
--
jmichell...@gmail.com
Hello,
I added manually a remote to .git/config, but updated only the url= line,
forgetting to update the fetch= line. So two
remotes had
fetch = +refs/heads/*:refs/remotes/origin/*
and fetching from the one or the other has overwritten origin/master. git fsck
has not helped.
Please introd
Hi,
Matthew DeVore wrote:
> I'm considering implementing a feature in the Git protocol which would
> enable efficient and accurate object negotiation when the client is a
> partial clone. I'd like to refine and get some validation of my
> approach before I start to write any code, so I've written
On Mon, May 06, 2019 at 10:38:12AM -0500, Robert Dailey wrote:
> I feel like you got hung up too much on exact wording of what I was
> trying to describe. I do apologize I don't have the background to
> explain things 100% accurately, especially at a low level. My
> explanations are mostly intended
I feel like you got hung up too much on exact wording of what I was
trying to describe. I do apologize I don't have the background to
explain things 100% accurately, especially at a low level. My
explanations are mostly intended to be as a user, based on what is
observable, and based on intent. I'l
On Mon, May 06, 2019 at 01:03:54PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Apr 29 2019, Denton Liu wrote:
>
> >> Subject: [PATCH v5 0/3] *** SUBJECT HERE ***
> >
> > I forgot to change the subject... Embarassing.
>
> Do you use git-send-email with --force? We should detect & stop these
On 08/Apr/2019 12:54, Ismael Luceno Cortes wrote:
> - Control+BackSpace: Delete word to the left of the cursor.
> - Control+Delete : Delete word to the right of the cursor.
>
> Originally introduced by BRIEF and Turbo Vision between 1985 and 1992,
> they were adopted by most CUA-Compliant UIs, i
Hi everyone,
there is an interesting wart around prompt.c -
PROMPT_ECHO isn't used in invoking an external helper program.
Thus, if I clone something on https (which requires auth for that),
and have SSH_ASKPASS set, I will get two GUI *password* prompts,
even though the first one will indicate i
On 5/6/2019 4:27 AM, Christian Couder wrote:
> On Fri, May 3, 2019 at 3:44 PM Ævar Arnfjörð Bjarmason
> wrote:
>> 1) We can stat() the "commit-graphs" directory to see if there's any
>>new/deleted ones (dir mtime changed), similar to what we do for the
>>untracked cache, and can (but I do
On Mon, Apr 29 2019, Denton Liu wrote:
>> Subject: [PATCH v5 0/3] *** SUBJECT HERE ***
>
> I forgot to change the subject... Embarassing.
Do you use git-send-email with --force? We should detect & stop these
being sent out otherwise. See a03bc5b6ad ("send-email: Refuse to send
cover-letter temp
On Tue, Mar 19 2019, Jeff King wrote:
> On Mon, Mar 18, 2019 at 11:45:39PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> > I don't think the quarantine stuff should impact contention at all. It's
>> > only quarantining the objects, which are the least contentious part of
>> > Git (because object co
On Mon, May 6, 2019 at 12:13 PM Jeff King wrote:
> This reduces the time required to run make coccicheck by a significant
> amount of time:
>
> Prior timing of make coccicheck
> real6m14.090s
> user25m2.606s
> sys 1m22.919s
>
> New timing of make coccicheck
> real1m36.580s
On Thu, Apr 25, 2019 at 8:15 PM Junio C Hamano wrote:
> * nd/config-move-to (2019-01-14) 7 commits
> - config.h: fix hdr-check warnings
> - config: add --move-to
> - config: factor out set_config_source_file()
> - config: use OPT_FILENAME()
> - config.c: add repo_config_set_worktree_gently()
On Fri, May 3, 2019 at 3:44 PM Ævar Arnfjörð Bjarmason wrote:
>
>
> On Fri, May 03 2019, Derrick Stolee wrote:
>
> > On 5/2/2019 2:02 PM, Ævar Arnfjörð Bjarmason wrote:
> >>
> >> But those are separate from any back-compat concerns, which is what I
> >> think makes sense to focus on now.
> >
> > T
>>> Andreas Schwab schrieb am 05.05.2019 um 22:31 in
Nachricht <87o94gbq46@igel.home>:
> On Mai 05 2019, "Ulrich Windl" wrote:
>
>> After that a "git diff ‑‑cached file" just shows the changes added
> interactively, but when I "git add file" to commit those changes), even the
> unstaged ch
52 matches
Mail list logo
