Jeff King <p...@peff.net> 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. "git stash --help" says
that "list" takes any random option that you can give to "git log",
and at that point you need to be very well aware what you are
telling "log" to show and how.
It probably *was* a UI mistake to make "list" just delegate to "log"
and it was a graver UI mistake that it was documented as such;
otherwise we could have limited option set "git stash list" would
take, which can be totally independent from what "git log" takes,
and we could just have said "git stash list -p" is a way to view
each entry with patch in a reasonable representation. But that
ideal world no longer exists X-<.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html