From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: <git@vger.kernel.org>
Subject: Re: [PATCH 3/4] merge-recursive: improve auto-merging messages with path collisions
Date: Mon, 15 Oct 2018 14:18:51 +0900 [thread overview]
Message-ID: <xmqq4ldn6b44.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20181012212551.7689-4-newren@gmail.com> (Elijah Newren's message of "Fri, 12 Oct 2018 14:25:50 -0700")
Elijah Newren <newren@gmail.com> writes:
> Each individual file involved in a rename could have also been modified
> on both sides of history, meaning it may need to have content merges.
> If two such files are renamed into the same location, then on top of the
> two natural auto-merging messages we also have to two-way merge the
> result, giving us messages that look like
>
> Auto-merging somefile.c (was somecase.c)
> Auto-merging somefile.c (was somefolder.c)
> Auto-merging somefile.c
>
> However, despite the fact that I was the one who put the "(was %s)"
> portions into the messages (and just a few months ago), I was still
> initially confused when running into a rename/rename(2to1) case and
> wondered if somefile.c had been merged three times. Update this to
> instead be:
>
> Auto-merging version of somefile.c from somecase.c
> Auto-merging version of somefile.c from someportfolio.c
> Auto-merging somefile.c
>
> This is an admittedly long set of messages for a single path, but you
> only get all three messages when dealing with the rare case of a
> rename/rename(2to1) conflict where both sides of both original files
> were also modified, in conflicting ways.
Yeah, that does look mouthful, but definitely is more
understandable.
next prev parent reply other threads:[~2018-10-15 5:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-12 21:25 [PATCH 0/4] More merge cleanups Elijah Newren
2018-10-12 21:25 ` [PATCH 1/4] t6036: add testcase where virtual merge base contains nested conflicts Elijah Newren
2018-10-12 21:25 ` [PATCH 2/4] merge-recursive: increase marker length with depth of recursion Elijah Newren
2018-10-15 5:12 ` Junio C Hamano
2018-10-15 15:02 ` Elijah Newren
2018-10-16 2:16 ` Junio C Hamano
2018-10-16 18:00 ` Elijah Newren
2018-10-12 21:25 ` [PATCH 3/4] merge-recursive: improve auto-merging messages with path collisions Elijah Newren
2018-10-15 5:18 ` Junio C Hamano [this message]
2018-10-12 21:25 ` [PATCH 4/4] merge-recursive: Avoid showing conflicts with merge branch before HEAD Elijah Newren
2018-10-15 5:23 ` Junio C Hamano
2018-10-16 20:19 ` [PATCH v2 0/2] More merge cleanups Elijah Newren
2018-10-16 20:19 ` [PATCH v2 1/2] merge-recursive: improve auto-merging messages with path collisions Elijah Newren
2018-10-16 20:19 ` [PATCH v2 2/2] merge-recursive: avoid showing conflicts with merge branch before HEAD Elijah Newren
2018-10-18 6:09 ` Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq4ldn6b44.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.