Stephen Leake <stephen_le...@stephe-leake.org> writes: > Brandon McCaig <bamcc...@gmail.com> writes: > >> On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake >> <stephen_le...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
