|
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 #!/bin/bash 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk