git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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:41:00 -0500	[thread overview]
Message-ID: <CAHd499DvwcHGkSF6DjivvceUaMRO994Q8e1JrjNqjzpQkhDMFg@mail.gmail.com> (raw)
In-Reply-To: <CAHd499BkdpsA2BdB0Hsv3xXzpMyMzW8CSuYf2gQX0Jf7OoYBGw@mail.gmail.com>

On Tue, May 7, 2019 at 9:10 AM Robert Dailey <rcdailey.lists@gmail.com> wrote:
> 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.

Also I'm really confused how you got diff-tree to work. If I pick any
arbitrary SHA1 of a merge commit in my existing repo's history,
diff-tree produces only a SHA1 as the result:

$ git diff-tree --cc bdd47a73d
bdd47a73d18948aa46a8a7aa964543f0d989ffd4

I tried with just `-c` as well; same result.

  reply	other threads:[~2019-05-07 14:41 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
2019-05-07 14:41         ` Robert Dailey [this message]
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=CAHd499DvwcHGkSF6DjivvceUaMRO994Q8e1JrjNqjzpQkhDMFg@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).