Re: [boost] git cherry-pick (Was: RE process (prospective from a retired FreeBSD committer)...)

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

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-avoiding-duplicate-commits/
>> -- 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
[phone]