From: Robert Dailey <rcdailey.lists@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "Eckhard Maaß" <eckhard.s.maass@googlemail.com>,
Git <git@vger.kernel.org>
Subject: Re: Merge commit diff results are confusing and inconsistent
Date: Tue, 7 May 2019 09:10:12 -0500 [thread overview]
Message-ID: <CAHd499BkdpsA2BdB0Hsv3xXzpMyMzW8CSuYf2gQX0Jf7OoYBGw@mail.gmail.com> (raw)
In-Reply-To: <874l67i1ie.fsf@evledraar.gmail.com>
On Mon, May 6, 2019 at 6:52 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> Maybe an example helps, let's say you have two paint buckets, one with
> red paint, one with yellow paint. You mix them. What happens?
>
> (
> rm -rf /tmp/git &&
> git init /tmp/git &&
> cd /tmp/git &&
> git checkout -b red &&
>
> echo red >color.txt &&
> git add color.txt &&
> git commit -m"red" &&
>
> git checkout --orphan green &&
> git reset --hard &&
> echo green >color.txt &&
> git add color.txt &&
> git commit -m"green" &&
>
> git merge --allow-unrelated-histories red;
> echo yellow >color.txt &&
> git add color.txt &&
> git commit -m"red + green = yellow"
> )
>
> I *think* what you're alluding to is trying to discover some sort of
> change to whatever the default merge resolution would have been, which
> in this case would be closer to:
>
> (echo green && echo red) >color.txt
>
> But it's important to understand that the whole business of suggesting
> how you should merge is just sugar that isn't in any way represented in
> the object model that makes it into the repository.
>
> In that model we just had one branch with "color.txt" containing "red",
> and another with "green". Then we merged the two together and that
> commit merged two histories together, did something to yield an end
> result, and now the "color.txt" file contains "yellow".
>
> But what single thing can you look at to describe how you ended up with
> "yellow"? There isn't such a single thing, I just know that I have a
> commit with two parents:
>
> $ git cat-file -p HEAD
> tree 6318a50d67e6de533498a4a0c9f46360cff6908a
> parent 2332fc6b40c1cbf9f5daf809f09eb4defdd2ce30
> parent 1707f13d2d236d61ac7496962ecebc50ffff5be3
>
> And that if I diff against the 1st parent we went from green to yellow:
>
> $ git diff HEAD^1..HEAD
> diff --git a/color.txt b/color.txt
> index a5b73ed..d1ed081 100644
> --- a/color.txt
> +++ b/color.txt
> @@ -1 +1 @@
> -green
> +yellow
>
> And the other from red to yellow:
>
> $ git diff HEAD^2..HEAD
> diff --git a/color.txt b/color.txt
> index a9d1386..d1ed081 100644
> --- a/color.txt
> +++ b/color.txt
> @@ -1 +1 @@
> -red
> +yellow
>
> To the extent that we can show a single diff at all that's diff-tree's
> --cc option:
>
> $ git diff-tree --cc HEAD
> e89ef1f780d7c979c18cc0f03fd74c560466ef03
> diff --cc color.txt
> index a5b73ed,a9d1386..d1ed081
> --- a/color.txt
> +++ b/color.txt
> @@@ -1,1 -1,1 +1,1 @@@
> - green
> -red
> ++yellow
>
> Sometimes it makes things better, sometimes it's just more
> confusing. It's what "git show" will use to render merge commits.
Your example is very helpful. I understand what you're saying for
conflicted lines. But the "whatever the default merge resolution would
have been" doesn't exist, because there's no reality where line 1 in
color.txt can be something "automatic" (i.e. deduced by git). The only
reality for the merge commit is some hand-edited replacement to line
1. So there is no "diff what I see with some alternate reality".
The majority use case I'm interested in is seeing net-positive changes
that happen in merge commits. Normally I take for granted that merge
commits have nothing meaningful in them (meaningful here defined as
something unexpected for a merge commit). But what if someone makes a
poor decision and does some crazy refactoring in 1 file and amends it
into a merge commit? Let's also say that these changes are done to a
file that wasn't modified in any parent (say a unrelated.txt next to
your color.txt). Since neither parent cares about that file for the
purposes of the merge, I am trying to make sense of a revision
specification that can be used to see what they did to that file.
Even ignoring that issue, the more concerning observation of mine is
that `diff @^!` produces any output at all. If you exclude both
parents, why do I see a diff for parent 2 (I see the complete diff of
the branch that was merged in)?
Again, thank you for your example, you definitely made things very
clear for me. I see where the confusion is. And I think --cc is a good
way to get more context. At this point I'm just concerned about the
@^! behavior with merge commits & diff.
next prev parent reply other threads:[~2019-05-07 14:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-03 15:55 Merge commit diff results are confusing and inconsistent Robert Dailey
2019-05-03 19:12 ` Eckhard Maaß
2019-05-06 15:38 ` Robert Dailey
2019-05-06 16:52 ` Eckhard Maaß
2019-05-06 23:52 ` Ævar Arnfjörð Bjarmason
2019-05-07 14:10 ` Robert Dailey [this message]
2019-05-07 14:41 ` Robert Dailey
2019-05-07 14:58 ` Denton Liu
2019-05-07 15:55 ` Eckhard Maaß
2019-05-07 15:26 ` Ævar Arnfjörð Bjarmason
2019-05-07 16:44 ` Elijah Newren
2019-05-11 14:08 ` Philip Oakley
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=CAHd499BkdpsA2BdB0Hsv3xXzpMyMzW8CSuYf2gQX0Jf7OoYBGw@mail.gmail.com \
--to=rcdailey.lists@gmail.com \
--cc=avarab@gmail.com \
--cc=eckhard.s.maass@googlemail.com \
--cc=git@vger.kernel.org \
/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).