Re: `git stash pop` UX Problem

[David Kastrup <dak@gnu.org>]

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

> For example, when I have conflicts from a 'git stash pop', 'git
> status' shows:
>
> stephe@takver$ git status
> # On branch master
> # Unmerged paths:
> #   (use "git reset HEAD <file>..." to unstage)
> #   (use "git add/rm <file>..." as appropriate to mark resolution)
> #
> #	both modified:      CommandBasedAutonomous.java
> #	both modified:      DriveByInches.java
> #
> # ...
>
> How does it know those files are "unmerged"? I'm guessing it has
> recorded the fact that they had conflicts. Where does it record that?

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.

After "git add", there is only one version in the index.

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.

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.

-- 
David Kastrup