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: Vladimir Prus (vladimir_at_[hidden])
Date: 2011-01-30 16:05:41

Dean Michael Berris wrote:

> 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).
...
> PS. Of course this only makes sense on repositories you actually
> control -- i.e. locally. 

Exactly, so this does not work for the case of cherry-pick from long-lived
public development branch of library X to release branch.

Now, this use of git rebase appears to contradict my earlier statements
that git cannot record cherry-pick merges, so I went to investigate, and,
unfortunately, discovered a bug in my script. Instead of simulating the
'I did cherry-pick, found conflicts, and edited them' use case it simulates
'I did cherry-pick, and then edited the same lines in another commit' use
case. So, I've modified the script to do the right thing (see below), and
rebase trick no longer works. In fact, rebase itself causes a conflict.

Looks like git cherry-pick is still deficient.

- Volodya

-- 
Vladimir Prus
Mentor Graphics
[phone]
#!/bin/bash
set -e
rm -rf /tmp/merge.git
mkdir /tmp/merge.git
cd /tmp/merge.git
git init
for i in {1..100}; do echo A$i >> file; done
git add file
git commit -m "Initial version"
git checkout -b feature
perl -pi -e 's|A1|A1_|' file
git commit -a -m "C1"
perl -pi -e 's|A50|A50_|' file
git commit -a -m "C2"
perl -pi -e 's|A90|A90_|' file
git commit -a -m "C3"
git checkout master
# Cherry-pick C2. To simulate conflict resolution, don't
# commit it yet.
git cherry-pick -n feature^
# Edit C2, as if we had a conflict and resolved it
perl -pi -e 's|A50_|A50__|' file
# Commit the result.
git commit -a -C feature^
# Do irrelevant change.
perl -pi -e 's|A65|A65_|' file
git commit -a -m "Do something after cherry-pick"
# Uncomment to try to use 'rebase' trick
# git checkout feature
# git rebase master
# Try to merge feature into master
git checkout master
git merge -s resolve feature