Re: git add -p and unresolved conflicts
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:53:25
Holger Hellmuth [off-list ref] writes:
But the conflicted chunks are of the form "<<<< our ... |||||||||| theirs >>>>>>" in your work tree. So there are two cases: a) You have removed the markers thereby removing the conflict -> this means the chunk will not be offered to you as a conflicting chunk b) You haven't removed the markers. Then there is a choice between base, our and their version. If you had edited one of the versions between the conflict markers in your working tree without removing the markers (which wouldn't be a sensible thing) then it depends on whether the chunk in the working tree or the versions in the index are used as a basis for the choosing, but I suspect using the working tree version is easier to do.
I think Matthieu is not thinking about the "resolve conflicted merge (or rebase, am) and make a single commit" use case, for which your "pick one of the sides" makes sense. His is more about "I like some change in that unrelated commit---while I have no intention to replay that change as a whole, I want to use "cherry-pick --no-commit" and pick only the bits out of the change that are useful for what I am doing" use case. In such a context, after resolving conflicts in the working tree, "add -p" would be a good tool to pick hunks in the diff between the HEAD and the working tree. I tend to think that use case, while valid, may be a minority case and giving a version of "add -p" to make that mode too easy to use by mistake during a true conflict resolution is inviting trouble for newbies. As I said, "reset $path" followed by regular "add -p $path" would be a usable workaround for Matthieu's workflow.