Vladimir Prus wrote:
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.
So, we spoke with Dean on IRC. His suggestion was to use git merge -s recursive -X ours for merging, but that would not work either -- it will prefer local versions for all conflics -- not something you want during regular development. No better ideas exist. So, to summarize, if I have a trunk branch and a release branch, Subversion allows me to pick a change on trunk branch, merge it to release branch, resolve any conflicts that arise, and forget about it, knowing that when I get to doing wholesale merge of the trunk branch, Subversion will not try to re-apply that change again. No similar mechanism for git has been demonstrated. If I do cherry-pick and get a conflict, then even if I resolve that conflict and is happy, there's no way to instruct git not to merge that revision again. - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40