Re: `git stash pop` UX Problem

From: Stephen Leake <stephen_leake@stephe-leake.org>
Date: Mar 1, 2014, 08:47 UTC
Message-ID: <85bnxq1f0v.fsf@stephe-leake.org>
In-Reply-To: <xmqqeh2nw2p4.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 20 quoted lines

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>
>>> 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.
>
> 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