git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <newren@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] merge-recursive: Fix multiple file rename across D/F conflict
Date: Fri, 20 Aug 2010 06:47:37 -0600	[thread overview]
Message-ID: <AANLkTin+keov7xDnXZVWzWVkQRqdfPEKBnpkzn27fUC+@mail.gmail.com> (raw)
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:
> Elijah Newren <newren@gmail.com> writes:
>
>> I'm really embarrased about this one...  :-/
>
> Let's embarrass you even more ;-)

Mission accomplished.  :-/

> 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) {

      reply	other threads:[~2010-08-20 12:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-17 23:53 [PATCH 0/2] Fix multiple file rename across D/F conflict Elijah Newren
2010-08-17 23:53 ` [PATCH 1/2] t6031: Add a testcase covering multiple renames across a " Elijah Newren
2010-08-17 23:53 ` [PATCH 2/2] merge-recursive: Fix multiple file rename across " Elijah Newren
2010-08-18 19:00   ` Junio C Hamano
2010-08-18 23:17   ` Junio C Hamano
2010-08-20 12:47     ` Elijah Newren [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTin+keov7xDnXZVWzWVkQRqdfPEKBnpkzn27fUC+@mail.gmail.com \
    --to=newren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).