Re: `git stash pop` UX Problem

Matthieu Moy [off-list ref] writes:

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 condition for dropping the stash should be more "conflits
resolutions are done AND the user is happy with it". Otherwise, if you
mess up your conflict resolution, and notice it after running "git add",
then you're screwed because Git just happily discarded your important
data. The point of keeping the stash is to leave it up to the user to
decide between "I'm happy, I can drop" or "I'm not, I should re-apply",
and Git cannot tell which is which.

Yes, that makes sense.

Hinting the user to run "stash pop" would be more acceptable, but
talking about "git stash" in "git add"'s code is somehow a dependency
order violation (stash is normally implemented on top of Git's basic
features, not the other way around). Does not seem serious from at first
from the user point of view, but this pushes the codebase one step in
the direction of an unmaintainable mess.

Also makes sense.

So "git add" and "git stash *" are lower level tools; to get the effect
we are asking for, we should use a front-end (which is why I'm writing
one for Emacs :).

-- 
-- Stephe