Re: git add -p and unresolved conflicts

[Junio C Hamano <gitster@pobox.com>]

Holger Hellmuth <hellmuth@ira.uka.de> 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.