git show -m with a parent number

Hi All,

is there a good reason for `git show -m` to not accept the number of a parent of a merge commit? I can run `git show --first-parent COMMIT`, but need to write `git diff COMMIT^2 COMMIT` every time I want to diff with the second parent!

`git cherry-pick -m 2 COMMIT` works, so why can't `git log` work like that?

On Sun, Mar 27, 2016 at 08:46:02PM +0000, Anatoly Borodin wrote:

I think it could, but nobody has yet found it useful enough to implement.

I am not sure of the workflow it would help. Personally, I use "-m" in two situations:

  1. To puzzle out issues where "-c" or "--cc" do not show what I
     expected.

  2. With "--first-parent", to follow the linear history of a mainline
     branch, showing merged topic branches as a single diff.

For the first one, showing all diffs is what I want. For the second, it only makes sense to for the first parent case, as following other parents would zig-zag through history.

But perhaps you have some other use case in mind. In cases like these, I think it is a good idea to implement the feature, and run with it for a while, seeing how it can be used. And then if it proves useful, post the patch to the list describing your experiences.

-Peff

Jeff King <peff@peff.net> writes:

For "git show" that does not traverse the history, there may be occasions where showing a diff with the second parent might make sense (e.g. the user merged two histories in a wrong direction in the past and it is too late to rewrite).

I think there are two reasons behind the current state. Because it does not make any sense for "git log -m 2" to show diff with its second parent while traversing many commits, the "git log" codepath is not prepared to show diff with only nth parent. Because "git show" started its life merely as a thin wrapper around "git log", "git show" does not use such an underlying machinery to show diff with only nth parent that does not exist.

Hi!

Jeff King <peff@peff.net> wrote:

Lucky you! :) You probably don't need to inspect 9 month old ex-svn branches with sync (i.e. 'trunk'->'feature') merges

*-...-*-...-*-...-*-.......-*---trunk
 \     \     \     \       /
  *-...-*-...-*-...-*-...-*---feature

(Not to forget some funny legacy inter-feature merges.)

It's not like `git diff X^2 X` is a big problem, but too much of a copypaste.

The other thing that bugs me is that you can easily `git cherry-pick -m 2 X`, but to see the diff that you are going to apply is not that trivial.

I'll try. BTW, should it be like '-m[=parent]' for consistency, or '-m [parent]' is ok?

PS Another idea:

'-m parent' makes sence in a normal, 2-branch merge. But what to do in a case of an octopus merge? In a normal case I can treat '-m 2' as 'the diff regarding the second parent', but also as 'the changes contributed by the first parent (plus "evil")'. But with 3 and more branches '-m 3' means 'the changes from 1 and 2'. Would it be possible to get only the contribution from the second or third parent in this case?

Yeah, I know, there is `git diff parent1...parent3` etc, but not all the changes from parent3 will always get to the merge commit.

Anatoly Borodin <anatoly.borodin@gmail.com> writes:

Brace expansion helps a bit: git diff X{^2,}

Andreas.