Subject: Re: `git stash pop` UX Problem

From: Stephen Leake <[email-masked]>
Date: Sat, 01 Mar 2014 02:47:44 -0600

Junio C Hamano <[email-masked]> writes:

> Stephen Leake <[email-masked]> writes:
>
>> Matthieu Moy <[email-masked]> writes:
>>
>>> [email-masked] (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.
>
> 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