Subject: Re: [boost] git cherry-pick (Was: RE process (prospective from a retired FreeBSD committer)...)
From: Christopher Jefferson (chris_at_[hidden])
Date: 2011-01-30 18:14:53
On 30 Jan 2011, at 21:05, Vladimir Prus wrote:
>
> 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.
I agree this is a problem with git. I think the problem is having a "trunk" which is merged piece-meal into a release branch. This is an unusual method of development, I'm not sure of any other large projects which have the a long-lived trunk and release, with merges from trunk to release. git does not support this well.
Of course, boost should not change it's development model just to support a different tool. But, if the development model did change, git might accommodate that better.
Chris