Re: git add -p and unresolved conflicts

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 28, 2012, 20:50 UTC
Message-ID: <7vvclotpp7.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4F737027.5020503@ira.uka.de>

Holger Hellmuth <hellmuth@ira.uka.de> writes:

Show 14 quoted lines

> 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.