Re: [PATCH 2/2] merge-recursive: Fix multiple file rename across D/F conflict
- From
Elijah Newren <newren@gmail.com>
- Date
- Aug 20, 2010, 12:47 UTC
- Message-ID
- <AANLkTin+keov7xDnXZVWzWVkQRqdfPEKBnpkzn27fUC+@mail.gmail.com>
- In-Reply-To
- <7v8w438q9k.fsf@alter.siamese.dyndns.org>
On Wed, Aug 18, 2010 at 5:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 5 quoted lines
> Elijah Newren <newren@gmail.com> writes: > >> I'm really embarrased about this one... :-/ > > Let's embarrass you even more ;-)
Mission accomplished. :-/
Show 40 quoted lines
> After 5a2580d, the merge has become very noisy, and I don't see a good > reason for that change. > > With a version of git built from 5a2580d^, for example, merging > sp/fix-smart-http-deadlock-on-error into maint would give me this: > > ---------------- > $ git merge sp/fix-smart-http-deadlock-on-error > Auto-merging remote-curl.c > Merge made by recursive. > remote-curl.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > ---------------- > > With 5a2580d, it has become this: > > ---------------- > $ git merge sp/fix-smart-http-deadlock-on-error > Adding builtin/add.c > Auto-merging remote-curl.c > Merge made by recursive. > remote-curl.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > ---------------- > > And with this patch on top, it will make it a disaster: > > ---------------- > $ git merge sp/fix-smart-http-deadlock-on-error > Adding builtin/add.c > ... similar 97 Adding lines omitted ... > Adding gitweb/static/gitweb.js > Auto-merging remote-curl.c > Adding t/lib-t6000.sh > Adding t/t7810-grep.sh > Adding t/t9350-fast-export.sh > Merge made by recursive. > remote-curl.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > ----------------
Ick.
Interestingly, the new paths I added for additional output are not being triggered here. Rather, "normal" renames are being considered unprocessed (I had a faulty assumption in the previous patch that a clean merge would have cleared out the higher stage entries in dst_entry as a side effect). Because of this, normal renames are needlessly re-processed in process_entry(), and trigger extra output as a side-effect. One could work around this by the following patch, though it'd be better to just avoid the extra reprocessing. I'll submit a better patch in a minute.
diff --git a/merge-recursive.c b/merge-recursive.c index 7ac0f57..5ec7f70 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -75,6 +75,7 @@ struct stage_data unsigned char sha[20]; } stages[4]; unsigned processed:1; + unsigned silent:1; }; static int show(struct merge_options *o, int v) @@ -1033,9 +1034,11 @@ static int process_renames(struct merge_options *o, * conflict) that need to be resolved. */ for (i = 1; i <= 3; i++) { if (!ren1->dst_entry->stages[i].mode) continue; ren1->dst_entry->processed = 0; + ren1->dst_entry->silent = 1; break; } } else { @@ -1188,7 +1198,8 @@ static int process_entry(struct merge_options *o, remove_file(o, 0, path, !a_sha); return 1; /* Assume clean till processed */ } else { - output(o, 2, "Adding %s", path); + if (!entry->silent) + output(o, 2, "Adding %s", path); update_file(o, 1, sha, mode, path); } } else if (a_sha && b_sha) {