Re: [PATCHv3] Add branch management for releases to gitworkflows
- From
- Raman Gupta <rocketraman@fastmail.fm>
- Date
- Nov 14, 2009, 05:35 UTC
- Message-ID
- <4AFE41AF.8050802@fastmail.fm>
- In-Reply-To
- <20091114081040.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
Show 21 quoted lines
> Quoting Raman Gupta <rocketraman@fastmail.fm> >> I noticed you removed the discussion I added about the situation in >> which maint will *not* be a subset of master i.e. when the user has >> cherry-picked commits from other branches. This type of cherry-pick is >> described as a valid operation, though one to generally be avoided >> earlier in the man page. If we tell users that the occasional >> cherry-pick to maint is ok, then shouldn't we explain how that affects >> the release process? > > It is irrelevant that you can cherry-pick to 'maint'. > > You can, and Junio does, cherry-pick some commits from master to > maint from time to time. But even if you have such cherry-picked > commits on the maintenance branch, the result, with zero or more > other maintenance commits on top, is always merged back to the > master branch (you can look at "gitk origin/maint origin/master" > to see yourself). > > So when Junio tags the release from the tip of the master branch, > it is a superset of the maintenace branch; it is irrelevant if > maint has some commits that are cherry-picked from master.
Thanks for the explanation. Makes sense.
Ok, another dumb question: since you have now submitted a patch on top of my patch, what is the proper etiquette for proceeding? Who maintains this patch series until it is committed? Since your patch applies on top of mine I can't really make any more changes without affecting your patch right? I can't find any guidance in the SubmittingPatches document.
Cheers, Raman