Holger Hellmuth <hellmuth@xxxxxxxxxx> writes: > 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) ? After re-reading what I wrote, I find that I misspoke. 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. 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". Which makes... > 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)... ...this part of your analysys (and your conclusion that he can take '<') invalid. Now I am not Matthieu, so he may have a different use case in mind when he said "I want to take the version from my working tree", but the sequence "cherry-pick --no-commit ; edit ; add ; commit" is a natural way to pick only a part relevant to your current work from unrelated commit, and I would understand why "Taking the version from my working tree" can be useful in such a scenario. In short, these two are totally different workflows and call for two different semantics. -- 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