Jeff King [off-list ref] writes:
So perhaps we could do something better on the viewing side, and
"simplify" combined merges for files with all-identical parents.
Or you can ask to show the difference with the first parent, no?
I do not think giving a single-parent diff when --cc/-c is asked
for, which is a clear indication that the caller is aware that the
commit in question is a merge, is such a good idea.
On Tue, Jul 29, 2014 at 10:00:22AM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
So perhaps we could do something better on the viewing side, and
"simplify" combined merges for files with all-identical parents.
Or you can ask to show the difference with the first parent, no?
Yeah, though there is no way to do the other thing (--second-parent to
show only the index side). I doubt anybody wants that, though. Just
passing --first-parent would probably be fine (that would match "git
stash show", too, though like that "stash show" it is impossible to
override to see the index portion then).
But...
I do not think giving a single-parent diff when --cc/-c is asked
for, which is a clear indication that the caller is aware that the
commit in question is a merge, is such a good idea.
I think that is my point, though. The user is _not_ aware that the
commit in question is a merge. They stashed some stuff, and now they
want to see the result. I'd like to show them a vanilla commit if the
index is irrelevant, and otherwise show them something more interesting.
I definitely don't think that should be the default behavior, but I
don't see a problem with it being part of stash. We pick apart the stash
already in git-stash.sh, so for "git stash show" we can do it ourselves.
But during a traversal, we need support from "git log", since the answer
is different for each stash (and even for each path).
-Peff