Re: [boost] git cherry-pick (Was: RE process (prospective from a retired FreeBSD committer)...)

Subject: Re: [boost] git cherry-pick (Was: RE process (prospective from a retired FreeBSD committer)...)
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-30 15:48:11

On Mon, Jan 31, 2011 at 4:16 AM, Vladimir Prus
<vladimir_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>
>> On Mon, Jan 31, 2011 at 3:07 AM, Vladimir Prus
>> <vladimir_at_[hidden]> wrote:
>>>
>>> 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.
>

Right, I had to run your script with chmod +x directly so that it
actually works locally. Silly me trying to do 'sh script.sh'.

>> 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.
>

Right. So I ran it and saw you had a conflict. Now looking at this
article (after a quick googling) :
http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/
-- it explains one way of doing it. Basically you rebase first before
you merge (which works for the case you point out).

Attached is the script that is modified to address the specific issue you raise.

HTH

PS. Of course this only makes sense on repositories you actually
control -- i.e. locally. If you're tracking a remote branch, this
could screw up your local branch -- in those cases it's best that you
actually have a branch from the remote tracking branch and rebase that
before you actually merge back into the "main" branch from which the
remote tracking branch is forked off. Your branch and the remote
branch can diverge (which actually happens quite a bit with git) but
with proper re-alignment procedures -- i.e. pulling or making sure
your changes are upstream -- these things can largely be avoided.

-- 
Dean Michael Berris
about.me/deanberris