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. "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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html