On Tue, Jul 29, 2014 at 12:27:07PM -0700, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
> > 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 actually think "git stash list" users should be made very aware
> that they are looking at merge commits, and also what two states
> each of these merge commits represents.
Yeah, I kind of agree, but I also am not optimistic about most users
understanding that. I was trying to gamble on the fact that:
1. Naive users who do not understand the index will not stage files
and then stash in the first place. To them, the stash would be a
simple diff between two states, the commit and the working tree.
2. Advanced users would see the more complicated diff, but only
because they were doing more interesting things with the index.
They know what the index is, and therefore know that stash must be
saving it somehow.
Of course that breaks down when the naive user somehow ends up with
staged content in the index (e.g., they are resolving a merge and try to
stash). Then they are thrust into the more complicated situation either
way.
I dunno. I suspect that gamble would work _most_ of the time, and makes
an OK default. On the other hand, "git stash list" was completely
useless for showing diffs for many years, and since becoming useful has
required "--cc" to show anything good. And this is the first complaint
we've seen on the list. Maybe people don't actually care, and educating
people to use "--cc -p" (or "--first-parent -p") is fine.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html