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