Boost logo

Boost :

Subject: Re: [boost] git cherry-pick (Was: RE process (prospective from a retired FreeBSD committer)...)
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2011-01-30 15:16:26

Dean Michael Berris wrote:

> On Mon, Jan 31, 2011 at 3:07 AM, Vladimir Prus
> <vladimir_at_[hidden]> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at