Re: `git stash pop` UX Problem

Brandon McCaig [off-list ref] writes:

Unlike a merge, when you pop a stash that history is lost. If you
screw up the merge and the stash is dropped then there's generally no
reliable way to get it back. I think that it's correct behavior for
the stash to not be dropped if the merge conflicts.

Agreed.

If there's any change that should be made it should be purely
providing more detailed instructions to the user about how to deal
with it.

Yes, there may be room for improvement, but that does not seem so easy.
Today, we have:

$ git stash pop
Auto-merging foo.txt
CONFLICT (content): Merge conflict in foo.txt

$ git status
On branch master
Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

        both modified:      foo.txt

=> The advices shown here are OK. Then:

$ git add foo.txt 
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   foo.txt

=> here, "git status" could have hinted the user "you may now run 'git
stash drop' if you are satisfied with your merge".

An obvious issue is that at this point Git has no way to know that you
just did a "git stash pop". But that could be solved by leaving a file
around like .git/stash-pop-ongoing.

Now, the real question is: when would Git stop showing this advice. I
don't see a real way to answer this, and I'd rather avoid doing just a
guess.

One easy thing to do OTOH would be to show a hint at the end of "git
stash pop"'s output, like

$ git stash pop
Auto-merging foo.txt
CONFLICT (content): Merge conflict in foo.txt
'stash pop' failed. Please, resolve the conflicts manually. The stash
was not dropped in case you need to restart the operation. When you are
done resolving the merge, you may run the following to drop the stash:

  git stash drop


or so (I couldn't find a concise yet accurate wording).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/