Re: `git stash pop` UX Problem

[Omar Othman <omar.othman@booking.com>]

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Holger Hellmuth <hellmuth@ira.uka.de> writes:
>>
>>> Am 24.02.2014 17:21, schrieb Matthieu Moy:
>>>> $ git add foo.txt
>>>> $ git status
>>>> On branch master
>>>> Changes to be committed:
>>>>     (use "git reset HEAD <file>..." to unstage)
>>>>
>>>>           modified:   foo.txt
>>> Maybe status should display a stash count if that count is > 0, as
>>> this is part of the state of the repo.
>> Maybe it would help some users, but not me for example. My main use of
>> "git stash" is a safe replacement for "git reset --hard": when I want to
>> discard changes, but keep them safe just in case.
>>
>> So, my stash count is almost always >0, and I don't want to hear about
>> it.
> "status" is about reminding the user what changes are already in the
> index (i.e. what you would commit) and what changes are in the
> working tree, from which you could further update the index with
> (i.e. what you could commit).
>
> One _could_ argue that stashed changes are what could be reflected
> to the working tree and form the source of the latter, but my gut
> feeling is that it is a rather weak argument.  At that point you are
> talking about what you could potentially change in the working tree,
> and the way to do so is not limited to "stash pop" (i.e. you can
> "git cherry-pick --no-commit $a_commit", or "edit" any file in the
> working tree for that matter, with the same ease).
>
> So, I tend to agree with you, while I do understand where "I want to
> know about what is in stash" is coming from (and that is why we do
> have "git stash list" command).
Same comment. Everyone will have his own opinion. As long as the 
messages are not customizable, we can debate for hours and everybody has 
a valid point.