Dean Michael Berris wrote:
On Mon, Jan 31, 2011 at 4:16 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Dean Michael Berris wrote:
On Mon, Jan 31, 2011 at 3:07 AM, Vladimir Prus <vladimir@codesourcery.com> 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-av... -- 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 +7 (812) 677-68-40 #!/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