Boost logo

Boost :

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

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?

- Volodya

Vladimir Prus
Mentor Graphics
+7 (812) 677-68-40
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 "C2"
git checkout master
git cherry-pick feature^
perl -pi -e 's|A50_|A50__|' file
git commit -a -m "Do something after cherry-pick"
git merge feature

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