Re: git add -p and unresolved conflicts

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.