All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Documentation: make 3-way merge warning more generic
Date: Sat, 01 Apr 2017 12:26:29 -0700	[thread overview]
Message-ID: <xmqqpogwszdm.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170401133124.10479-1-sandals@crustytoothpaste.net> (brian m. carlson's message of "Sat, 1 Apr 2017 13:31:24 +0000")

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

>  With the strategies that use 3-way merge (including the default, 'recursive'),
> -if a change is made on both branches, but later reverted on one of the
> -branches, that change will be present in the merged result; some people find
> -this behavior confusing.  It occurs because only the heads and the merge base
> -are considered when performing a merge, not the individual commits.  The merge
> -algorithm therefore considers the reverted change as no change at all, and
> -substitutes the changed version instead.
> +only the heads and the merge base are considered when performing a merge, not
> +the individual commits.  This means that if a change is made on both branches,
> +but later reverted on one of the branches, that change will be present in the
> +merged result; some people find this behavior confusing.  The merge algorithm
> +considers the reverted change as no change at all, and substitutes the changed
> +version instead.

I agree that it makes sense to say 3-way merge considers only three
points upfront.  

I do not think "this means" is helpful to the readers, though.  Drop
"This means that" and instead rewrite the remainder of the paragraph
after "present in the merged result", perhaps?

	If a change is made on both branches but later reverted on
	one of the branches, the net effect the branch that reverted
	the change has to the project is nothing, while the net
	effect of the other branch is to make that change.  The
	3-way merge, i.e. "if one branch did something while the
	other branch didn't do that something, merge result is to do
	that something", rule keeps the change in the merge result.

We do not need to say "some people find this confusing" buried in a
long paragraph, which would not even serve the purpose of attracting
readers' eyes by shouting "THIS MAY BE DIFFICULT, PAY ATTENTION".
The last sentence in the original (and your version) only repeats
the same thing without saying what the real 3-way merge rule is, and
I think a rewrite like the above that makes it more explicit is
easier to understand.



      reply	other threads:[~2017-04-01 19:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01 13:31 [PATCH] Documentation: make 3-way merge warning more generic brian m. carlson
2017-04-01 19:26 ` Junio C Hamano [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

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

  git send-email \
    --in-reply-to=xmqqpogwszdm.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    /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.