Re: git add -p and unresolved conflicts

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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.

Re: git add -p and unresolved conflicts

From: Holger Hellmuth <hidden>
Date: 2016-06-15 22:53:25

Am 28.03.2012 22:50, schrieb Junio C Hamano:
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.
Ok. Something like this (which is not really that different from Eriks 
example, so I might still be missing something) ?

git init .
echo "foo" > bar.txt
git add bar.txt
git commit -m.
git checkout -b new
echo "bar" >> bar.txt
git commit -am.
git checkout master
git reset --hard
echo "baz" >> bar.txt
git commit -am.
git cherry-pick --no-commit new
git add -p bar.txt

So he would be interested in keeping his previous working tree version 
(identical to HEAD commit, otherwise cherry-pick fails) for conflicting 
chunks as they (in most cases) don't have anything to do with the chunks 
he is interested in. In this case that is "baz"

Which would always be the "ours" side in any conflicting junks.

That suggests that he could just type '<' respective 'o' whenever a 
conflicting junk comes up as it would be the previous working tree version
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help