Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk