Re: `git stash pop` UX Problem

From: Stephen Leake <stephen_leake@stephe-leake.org>
Date: Feb 28, 2014, 17:45 UTC
Message-ID: <85r46n168a.fsf@stephe-leake.org>
In-Reply-To: <87mwhb1azp.fsf@fencepost.gnu.org>

David Kastrup <dak@gnu.org> writes:

Show 21 quoted lines

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> Brandon McCaig <bamccaig@gmail.com> writes:
>>
>>> On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
>>> <stephen_leake@stephe-leake.org> wrote:
>>>> 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.
>>>
>>> Staging a file doesn't tell git that you resolved a conflict. Git will
>>> happily accept a blob full of conflict markers. Git doesn't know the
>>> difference. Git expects the user to know what is right. The user has
>>> the freedom to manipulate the index as they see fit, which means both
>>> adding and removing from it anytime they wish.
>>
>> But git has a notion of "unresolved conflict".
>
> Not really.  It has a notion of "unmerged path".
>
> <snip>

> The index contains the unmerged versions of the file.  Possibly also the
> version with conflict markers, but it's been too long since I last
> checked.

Paraphrasing, is this correct?

    "the index contains both versions of the unmerged file; any file
     with more than one version in the index is unmerged".

So what 'git add' does in this case is replace both versions of the file in the index with a new version.

I was not aware that the git system could support more than one version of a file in one branch. That makes it more like monotone :).

> If you apply a stash with unmerged paths to a worktree/index, possibly
> containing unmerged paths of its own, possibly getting new unmerged
> paths by failing to apply the stash, you get unmerged paths from several
> different unresolved conflicts.

Yes; doing too many things at once is a bad idea. But that should never cause git to lose data or do something wrong.

At the same time, it seems all unmerged paths result from unresolved merge conflicts, so the two notions are equivalent for git?

> Git has no idea about the history of unmerged paths.  So having "git
> add" modify the operation of "git reset" whenever "git add" overwrites
> an unmerged path in the index could lead to quite funny results.

Ok; I'll take that as describing a large class of "bad thing" use cases.

-- 
-- Stephe