Re: `git stash pop` UX Problem

Stephen Leake [off-list ref] writes:

Brandon McCaig [off-list ref] writes:

quoted

On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
[off-list ref] wrote:

quoted

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