Hmmm.... this topic seems in part to be very close to my thread
"git merge" merges too much!
At Sun, 29 Nov 2009 18:02:32 +0100, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote:
Subject: Re: What is the best way to backport a feature?
>
> Seriously, I suggest reading up on "topic branches". Feature_A should
> have been based off the common merge base of Mainline and Release_1.0,
> and, even more importantly, there should not have been any merges from
> Mainline into Feature_A. So, that branch is not at all what one would
> call a feature branch/topic branch. Hopefully, this scenario is very
> uncommon :)
IFF I understand the original post correctly then actually in my
experience this scenario is VERY common in some environments!
This is exactly how large projects which use the likes of CVS (and SVN?)
manage longer-running development branches for important new features.
One excellent example is NetBSD (and perhaps the other BSDs too).
A developer creates a "working" branch from the trunk, then begins to
make changes and commits to that branch. Periodically the (entire)
trunk is merged again to the working branch. I think this is somewhat
equivalent to using "git rebase" to re-apply the feature branch to a new
fork point from the trunk. However the actual branch base point remains
at the original point -- it is only the delta between the last merge
from trunk and the current head of the trunk which is merged onto the
feature working branch. I think this is what people in the CVS world
mean when they say they want the tool to remember the point on the
source branch from where they did the last merge. They've got their
work-flow "backwards", but this is the best they can do with CVS.
These periodic merges from the trunk mean that once the feature is
finished the delta between the trunk and the new feature branch is going
to be just the new feature, and so merging that delta alone to the trunk
as one commit adds the new feature to the trunk with few or no
conflicts, and the feature working branch can finally be "closed".
I'm guessing that people moving to Git from CVS may choose to stick with
this pattern where they periodically merge-from-master to keep
long-running feature branches as close to in-sync with the master branch
as possible (to avoid final merge conflicts). Ideally, IIUC, perhaps
they should use rebase instead.
Perhaps this "mess" can indeed be cleaned up using "git rebase -i" so
that the final version of the feature branch can be back-ported more
easily (though one will still need to use git-cherry-pick or git-am to
do the back-port to the previous release branch). The result of the
cleanup, before the merge of Feature_A to 1.0 might look more like this:
o--o--o Release_1.0
/ \ \
o-o-o--o--o-o-o-o-o-o-o-o---------------o Mainline
\ /
F1'--F2'--F3' Feature_A
and then after the merge of Feature_A to Release_1.0:
o--o--o--F1''--F2''--F3'' Release_1.0
/ \ \
o-o-o--o--o-o-o-o-o-o-o-o---------------o Mainline
\ /
F1'--F2'--F3' Feature_A
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@xxxxxxxxxxx>
Planix, Inc. <woods@xxxxxxxxxx> Secrets of the Weird <woods@xxxxxxxxx>
Attachment:
pgp4IjDArpf8M.pgp
Description: PGP signature