From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Greg A. Woods" Subject: Re: What is the best way to backport a feature? Date: Mon, 30 Nov 2009 14:08:05 -0500 Message-ID: References: <4B12A928.2000401@drmicha.warpmail.net> Reply-To: The Git Mailing List Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Mon_Nov_30_14:08:05_2009-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: Peter Weseloh , The Git Mailing List To: Michael J Gruber X-From: git-owner@vger.kernel.org Mon Nov 30 20:08:29 2009 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1NFBbm-0004in-0I for gcvg-git-2@lo.gmane.org; Mon, 30 Nov 2009 20:08:26 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753258AbZK3TIK (ORCPT ); Mon, 30 Nov 2009 14:08:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753284AbZK3TIJ (ORCPT ); Mon, 30 Nov 2009 14:08:09 -0500 Received: from most.robohack.planix.com ([204.92.254.2]:60564 "EHLO most.weird.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753258AbZK3TIH (ORCPT ); Mon, 30 Nov 2009 14:08:07 -0500 Received: from once.weird.com ([204.92.254.13] port=52977) by most.weird.com([204.92.254.2] port=25) via TCP with esmtp (5318 bytes) (sender: ) (ident using rfc1413) id for ; Mon, 30 Nov 2009 14:08:09 -0500 (EST) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2009-Feb-3) In-Reply-To: <4B12A928.2000401@drmicha.warpmail.net> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.7 Emacs/22.3 (i386--netbsdelf) MULE/5.0 (SAKAKI) X-Face: ;j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz;@-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= X-Mailing-List: git@vger.kernel.org Archived-At: --pgp-sign-Multipart_Mon_Nov_30_14:08:05_2009-1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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 wrote: Subject: Re: What is the best way to backport a feature? >=20 > 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 --=20 Greg A. Woods +1 416 218-0098 VE3TCP RoboHack Planix, Inc. Secrets of the Weird --pgp-sign-Multipart_Mon_Nov_30_14:08:05_2009-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD) iD8DBQBLFBgVZn1xt3i/9H8RAoUIAJ0UpNcFdnPbJF55JnuQywe8kit87wCgtURX bKFbemcY9PdYj2Dfk9Wysig= =YpBi -----END PGP SIGNATURE----- --pgp-sign-Multipart_Mon_Nov_30_14:08:05_2009-1--