Re: [PATCH v2 8/9] rebase -i: learn to abbreviate command names

Hi Duy, On Mon, 25 Dec 2017 at 07:48 Duy Nguyen wrote: > > On Mon, Dec 4, 2017 at 5:17 AM, Liam Beguin wrote: > > +static const char command_to_char(const enum todo_command command) > > +{ > > + if (command < TODO_COMMENT &&

Re: [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory

Am 25.12.2017 um 01:28 schrieb Ævar Arnfjörð Bjarmason: +create_test_file() { + file=$1 + + case $file in + # `touch .` will succeed but obviously not do what we intend + # here. + ".") + return 1 + ;; + # We cannot create a file

Re: Error in `git': free(): invalid pointer (was Re: [PATCH] sequencer: improve config handling)

On Friday 22 December 2017 05:19 PM, Johannes Schindelin wrote: Hi Kaartic, I think I didn't mention I've set `commit.gpgsign` to `true` for that repo, did I? Hah! I had troubles to associate the correct line in my versions of Git's source code (the line numbers alone are only reliable if

Re: [BUG] File move with `add -N` shows as rename to same name

On Sat, Dec 23, 2017 at 9:42 AM, Alex Vandiver wrote: > I just stumbled across the following oddity: Thanks. I'm looking into it. -- Duy

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Fri, Dec 22, 2017 at 9:00 PM, Ævar Arnfjörð Bjarmason wrote: > The untracked cache gets confused when a directory is swapped out for > a symlink to another directory. Whatever files are inside the target > of the symlink will be incorrectly shown as untracked. This issue does

Re: Improved error handling (Was: [PATCH 1/2] sequencer: factor out rewrite_file())

Am 24.12.2017 um 15:54 schrieb Jeff King: On Sat, Nov 18, 2017 at 10:01:45AM +0100, Johannes Sixt wrote: Yeah, I have mixed feelings on that. I think it does make the control flow less clear. At the same time, what I found was that handlers like die/ignore/warn were the thing that gave the

[PATCH] Fix confusing wording

Not sure if I should add a CVE-2009-0037 reference as well. --- http.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/http.c b/http.c index 215bebe..26b3386 100644 --- a/http.c +++ b/http.c @@ -802,7 +802,7 @@ static CURL *get_curl_handle(void)

[PATCH] status: handle worktree renames

Before 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist in index" - 2016-10-24) there are never "new files" in the index, which essentially disables rename detection because we only detect renames when a new file appears in a diff pair. After that commit, an i-t-a entry can

Re: [PATCH v2 8/9] rebase -i: learn to abbreviate command names

On Mon, Dec 4, 2017 at 5:17 AM, Liam Beguin wrote: > +static const char command_to_char(const enum todo_command command) > +{ > + if (command < TODO_COMMENT && todo_command_info[command].c) > + return todo_command_info[command].c; > + return

Re: [PATCH] revision: introduce prepare_revision_walk_extended()

Am 24.12.2017 um 15:22 schrieb Jeff King: > The single-traversal thing I suspect doesn't matter much in practice. In > both cases if we would visit commit X twice, we'd immediately see on the > second visit that it has already been cleared and not do anymore work. Good point. That makes

[PATCH v2 0/9] revision: get rid of the flag leak_pending

The flag leak_pending is weird, let's get rid of it. Changes from v1: Everything. An independent optimization found while working on this series: commit: avoid allocation in clear_commit_marks_many() Trivial unrelated conversions (included as bonus patches): commit: use

[PATCH v2 1/9] commit: avoid allocation in clear_commit_marks_many()

Pass the entries of the commit array directly to clear_commit_marks_1() instead of adding them to a commit_list first. The function clears the commit and any first parent without allocation; only higher numbered parents are added to a list for later treatment. This change extends that

[PATCH v2 2/9] commit: use clear_commit_marks_many() in remove_redundant()

Signed-off-by: Rene Scharfe --- commit.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/commit.c b/commit.c index 82667514bd..9edc12f338 100644 --- a/commit.c +++ b/commit.c @@ -929,8 +929,7 @@ static int remove_redundant(struct commit **array, int cnt)

[PATCH v2 3/9] ref-filter: use clear_commit_marks_many() in do_merge_filter()

Signed-off-by: Rene Scharfe --- ref-filter.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/ref-filter.c b/ref-filter.c index 3f9161707e..f9e25aea7a 100644 --- a/ref-filter.c +++ b/ref-filter.c @@ -1995,8 +1995,7 @@ static void do_merge_filter(struct

[PATCH v2 5/9] bisect: avoid using the rev_info flag leak_pending

The leak_pending flag is so awkward to use that multiple comments had to be added around each occurrence. We only use it for remembering the commits whose marks we have to clear after checking if all of the good ones are ancestors of the bad one. This is easy, though: We need to do that for the

[PATCH v2 6/9] bundle: avoid using the rev_info flag leak_pending

The leak_pending flag is so awkward to use that multiple comments had to be added around each occurrence. We use it for remembering the prerequisites for the bundle. That is easy, though: We have the ref_list named "prerequisites" in the header for just that purpose. Use this original list of

[PATCH v2 4/9] object: add clear_commit_marks_all()

Add a function for clearing the commit marks of all in-core commit objects. It's similar to clear_object_flags(), but more precise, since it leaves the other object types alone. It still has to iterate through them, though. Signed-off-by: Rene Scharfe --- object.c | 11

[PATCH v2 9/9] commit: remove unused function clear_commit_marks_for_object_array()

Signed-off-by: Rene Scharfe --- commit.c | 14 -- commit.h | 1 - 2 files changed, 15 deletions(-) diff --git a/commit.c b/commit.c index 9edc12f338..ff51c9f34a 100644 --- a/commit.c +++ b/commit.c @@ -559,20 +559,6 @@ void clear_commit_marks(struct commit *commit,

[PATCH v2 7/9] checkout: avoid using the rev_info flag leak_pending

The leak_pending flag is so awkward to use that multiple comments had to be added around each occurrence. We only use it for remembering the commits whose marks we have to clear after checking if the old HEAD is detached. This is easy, though: We need to do that for the old commit, the new one

[PATCH v2 8/9] revision: remove the unused flag leak_pending

Signed-off-by: Rene Scharfe --- revision.c | 3 +-- revision.h | 12 2 files changed, 1 insertion(+), 14 deletions(-) diff --git a/revision.c b/revision.c index f6a3da5cd9..7239315de9 100644 --- a/revision.c +++ b/revision.c @@ -2860,8 +2860,7 @@ int

Re: [PATCH] setup.c: move statement under condition

On Sun, Dec 24, 2017 at 8:35 PM, Ævar Arnfjörð Bjarmason wrote: > > On Sun, Dec 24 2017, Kevin Daudt jotted: > >> On Sun, Dec 24, 2017 at 12:15:35PM +0400, Vadim Petrov wrote: >>> Thank you for your replay. >>> >>> > I have to be honest: this commit message (including the

Re: [PATCH] status: handle worktree renames

Hi Duy, On 25/12/2017 11:37, Nguyễn Thái Ngọc Duy wrote: > Before 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist > in index" - 2016-10-24) there are never "new files" in the index, which > essentially disables rename detection because we only detect renames > when a new file

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Mon, Dec 25 2017, Duy Nguyen jotted: > On Fri, Dec 22, 2017 at 9:00 PM, Ævar Arnfjörð Bjarmason > wrote: >> The untracked cache gets confused when a directory is swapped out for >> a symlink to another directory. Whatever files are inside the target >> of the symlink will

Re: Bring together merge and rebase

On Sun, Dec 24, 2017 at 10:52:15PM -0500, Theodore Ts'o wrote: > As a suggestion, before diving into the technical details of your > proposal, it might be useful consider the usage scenario you are > targetting. Things like "git rebase" and "git merge" and your > proposed "git replace/replay" are

Re: Bring together merge and rebase

On Mon, Dec 25, 2017 at 4:16 PM, Carl Baldwin wrote: > On Sat, Dec 23, 2017 at 11:09:59PM +0100, Ęvar Arnfjörš Bjarmason wrote: >> >> But I don't see why you think this needs a new "replaces" parent >> >> pointer orthagonal to parent pointers, i.e. something that would >> >>

Re: [PATCH] status: handle worktree renames

On Mon, Dec 25, 2017 at 07:26:27PM +0100, Igor Djordjevic wrote: > But I`ve noticed that "--porcelain=v2" output might still be buggy - > this is what having both files staged shows: > > $ git status --porcelain=v2 > 2 R. N... 100644 100644 100644 12f00e90b6ef79117ce6e650416b8cf517099b78

RE: Bring together merge and rebase

On December 25, 2017 6:44 PM Carl Baldwin wrote: > On Sun, Dec 24, 2017 at 12:01:38AM +0100, Johannes Schindelin wrote: > > On Sat, 23 Dec 2017, Carl Baldwin wrote: > > > I imagine that a "git commit --amend" would also insert a "replaces" > > > reference to the original commit but I failed to

Re: [PATCH] status: handle worktree renames

On 25/12/2017 20:45, Igor Djordjevic wrote: > > I guess an additional test for this would be good, too. ... aaand here it is. Again based on your test, but please double check, I`m not sure if it`s ok to compare file modes like that, expecting them to be the same (hashes should be fine, I

Re: Bring together merge and rebase

On Sun, Dec 24, 2017 at 12:01:38AM +0100, Johannes Schindelin wrote: > Hi Carl, > > On Sat, 23 Dec 2017, Carl Baldwin wrote: > > > I imagine that a "git commit --amend" would also insert a "replaces" > > reference to the original commit but I failed to mention that in my > > original post. > >

Re: Bring together merge and rebase

On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin wrote: > Anyway, now I am compelled to use github which is also a fine tool and I > appreciate all of the work that has gone into it. About 80% of the time, > I rebase and force push to my branch to update a pull request. I've come

Re: [PATCH v2 8/9] rebase -i: learn to abbreviate command names

On Mon, Dec 25, 2017 at 10:39 PM, Liam Beguin wrote: > I'm curious, how did you build to get this error to show? > I tried with the DEVELOPER 'flag' but nothing showed and -Wextra gave > way too much messages... > Did you just add -Wignored-qualifiers to CFLAGS? I have a

Re: [PATCH] status: handle worktree renames

On Tue, Dec 26, 2017 at 9:11 AM, Duy Nguyen wrote: > On Mon, Dec 25, 2017 at 07:26:27PM +0100, Igor Djordjevic wrote: >> But I`ve noticed that "--porcelain=v2" output might still be buggy - >> this is what having both files staged shows: >> >> $ git status --porcelain=v2 >>

Re: Bring together merge and rebase

On Mon, Dec 25, 2017 at 05:47:55PM -0800, Jacob Keller wrote: > On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin wrote: > > Anyway, now I am compelled to use github which is also a fine tool and I > > appreciate all of the work that has gone into it. About 80% of the time, > > I

Re: Bring together merge and rebase

On Sat, Dec 23, 2017 at 11:09:59PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> But I don't see why you think this needs a new "replaces" parent > >> pointer orthagonal to parent pointers, i.e. something that would > >> need to be a new field in the commit object (I may have misread the > >>

Re: [PATCH] status: handle worktree renames

On 25/12/2017 19:26, Igor Djordjevic wrote: > > But I`ve noticed that "--porcelain=v2" output might still be buggy - > this is what having both files staged shows: > > $ git status --porcelain=v2 > 2 R. N... 100644 100644 100644 12f00e90b6ef79117ce6e650416b8cf517099b78 >

Re: Bring together merge and rebase

On Sat, Dec 23, 2017 at 05:19:35PM -0500, Randall S. Becker wrote: > No matter how this plays out, let's please make very sure to provide > sufficient user documentation so that those of us who have to explain > the differences to users have a decent reference. Even now, explaining > rebase vs.