Re: cherry-pick --since ?

From: Junio C Hamano <junkio@cox.net>
Date: Apr 23, 2007, 19:32 UTC
Message-ID: <7v8xciga42.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0704231208490.4667@torch.nrlssc.navy.mil>

Brandon Casey <casey@nrlssc.navy.mil> writes:

Show 18 quoted lines

> On Fri, 20 Apr 2007, Junio C Hamano wrote:
>> Brandon Casey <casey@nrlssc.navy.mil> writes:
>> ...
>>> Here's my use case:
>>>
>>> Two branches, 'A' and 'B'.
>>> 'A' is the master branch.
>>> 'B' was forked some time ago and is in bug fix only mode.
>>> Much of 'A' and 'B' are still the same, but there have been
>>>   some intrusive changes made to 'A' that should not go into 'B'.
>>
>> You forgot to say "My objective is to make sure all the good
>> fixes in B are forward ported to A" but I am assuming that is
>> the case.
> 
> Yes, that is the case, but the flow is both ways. Other developers
> may implement fixes in 'A', which must be backported to 'B'. They
> don't care about 'B'.

That shows a problem in the project management that needs to be fixed independent of what SCM tool you use, doesn't it?

I do not think you would necessarily want to have a VC tsar to say "No, that is perfectly valid fix for the maintenance branch and you should make it go through the maintenance branch, do not directly commit to the master". People should be able to self-police that, with a general, shared understanding of what the overall process is, and can strive to make it easier for everybody.

Even with that, mistakes can happen, and sometimes you may realize that a fix or enhancement is applicable to the maintenance branch as well long after it hit the master branch. I would not disagree that you would need to have a way to deal with the ones that need backporting by cherry-picking (otherwise we would not have git-cherry-pick). And I am certainly not against a cherry-pick that can do more than one commit. What I am saying is that having to cherry-pick should be the exception, not the norm, and otherwise there is something wrong in the process.

If you want to do a cherry-pick that handles more than one commit, I think you need to worry about sequencing -- how to let the user continue after aborting in the middle and having him resolve conflicts. What "git-rebase --continue" does already can be used as a model for you to mimick in such an implementation.