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".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html