On Mon, 23 Apr 2007, Junio C Hamano wrote:
Brandon Casey <casey@xxxxxxxxxxxxxxx> writes:
On Fri, 20 Apr 2007, Junio C Hamano wrote:
Brandon Casey <casey@xxxxxxxxxxxxxxx> 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
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html