Dean Michael Berris wrote:
On Mon, Jan 31, 2011 at 3:07 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Dean Michael Berris wrote:
Now, let's say you finally merge the changes from the whole branch from which you cherry-picked a commit into the branch that has this cherry-picked change already applied, git is actually smart enough to see that the change is already there and would not have to apply it again
Sorry, this is false. If you have branch F with commits C1, C2 and C3, and you first cherry-pick C2 into M, and then merge F into M, then git will try to merge entire C1+C2+C3 delta. Therefore, you have modified, in M, any lines that C2 touches -- for examples because you've run into conflict when doing cherry-pick and changed something -- you will get a conflict, again. Please try the attached script -- which results in conflict with git 1.7.1, and used to result in conflict in every other version.
Am I missing something?
You might be... I had to modify it a bit, because 'feature^' is really not correct,
Uhm, why? feature is a refname that resolves to C3 (top commit on the 'feature' branch), feature^ is therefore C2. And 'git cherry-pick feature^' appears to work fine here.
but basically here is the new script (based on yours); note that I see no merge conflicts whatsoever and git doesn't complain. Are you sure this is supposed to fail because it doesn't fail from my end -- I'm using git 1.7.1 on Ubuntu Linux 10.10 64-bit...
Well, your new script cherry-picks C3, not C2, and since other bits are designed to generate conflict on C2, it's no wonder you get no conflict. - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40