On Mon, 23 Apr 2007, Junio C Hamano wrote:
quoted text
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> 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.

Agreed.

I think our case is more similar to a linux 2.6.20 branch and a
2.6.21 branch. Everybody's working on 2.6.21, but maybe someone is
still relying on 2.6.20. That person implements their patches on 2.6.20
and pushes them to 2.6.21. Meanwhile, important fixes may be applied to
2.6.21 which is the official development version. So those fixes that
are applicable to 2.6.20 must be pulled from 2.6.21 by the developer
with the interest in 2.6.20.

Comments below noted, and thanks for your help.

-brandon


quoted text
> 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.
>
>

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html