Re: `git stash pop` UX Problem

From: Stephen Leake <stephen_leake@stephe-leake.org>
Date: Feb 28, 2014, 02:57 UTC
Message-ID: <85fvn40ws9.fsf@stephe-leake.org>
In-Reply-To: <vpqmwhexidi.fsf@anie.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 8 quoted lines

> lists@haller-berlin.de (Stefan Haller) writes:
>
>> 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.

Show 7 quoted lines

> 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.

Show 6 quoted lines

> 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