Re: git add -p and unresolved conflicts

[Holger Hellmuth <hellmuth@ira.uka.de>]

Am 29.03.2012 01:01, schrieb Junio C Hamano:
> There is a crucial step missing.  After running "cherry-pick --no-commit",
> you would eyeball the result, and typically edit the file.  The conflict
> may not be in the part of the file you are interested in picking, in which
> case you may even leave that part as-is.  And then, you would pick what
> you want to apply to the index during per-hunk interactive patching
> session.

But that changes nothing. To make it clear: We have a file with chunks 
A, B and C. Only B is conflicting, but the user wants to add A or an 
edited A´ . And maybe also a new edit D.

When he calls "git add -p", he gets presented with B. By picking the 
"ours" option (aka "<") he gets the version in HEAD, resolving the 
conflict and thereby allowing the add. Next he will be presented with A 
(or A´) where he can type in "y" and C where he can type in "n".

Result: chunk A is added, C not, and B doesn't change from HEAD. Note he 
had the option to use ">" instead if it was B he wanted to cherry-pick.

The same happens if he further edited somewhere else to produce chunk D. 
Again, after resolving the conflict of B, he is presented with A,B and D 
and can add these chunks with "y" or not with "n".

The only case I haven't talked about now is if he edits B, but that is 
the trivial case because he would normally remove the conflict markers 
as well and git add -p would work conflict-free after the edit.

> In other words,...
>
>> 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
>
> Here, there *will* be "edit bar.txt" before "add -p".