Re: `git stash pop` UX Problem

Junio C Hamano [off-list ref] writes:

Stephen Leake [off-list ref] writes:

quoted

Matthieu Moy [off-list ref] writes:

quoted

lists@haller-berlin.de (Stefan Haller) writes:

quoted

Your intention was clearly to drop the stash, it just wasn't dropped
because of the conflict. Dropping it automatically once the conflict
is resolved would be nice.

Your intention when you ran "git stash pop", yes. Your intention when
you ran "git add", I call that guessing.

You might be adding other files for other reasons. But if you add a file
that does resolve a conflict caused by 'git stash pop', it is not
guessing.

The only thing you know for sure is that the user has consumed _one_
part of the stashed change, no?  What if the stash had changes for
more than one path?

Count the unmerged paths in the index; when the count is zero, all
conflicts are resolved.

paths in the stash that had no conflicts are already in the index.

So _if_ there is nothing going on except finishing the stash pop, an
unmerged path count of zero means you are done with the stash, and it
can be dropped.

At the time of "git add $path", can you reliably tell if the
conflict to the $path the user is resolving came from a previous
"git stash pop", not from any other mergy operations, e.g. "git
stash apply" or "git apply -3"?

This is the real problem. I can impose a rule on my team of "don't do
more than one merge at a time" by implementing that in the front-end,
but git can't assume that.

-- 
-- Stephe