Holger Hellmuth <hellmuth@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html