From: Raman Gupta <rocketraman@fastmail.fm>
To: Nanako Shiraishi <nanako3@lavabit.com>
Cc: git@vger.kernel.org, trast@student.ethz.ch, gitster@pobox.com
Subject: Re: [PATCHv3] Add branch management for releases to gitworkflows
Date: Sat, 14 Nov 2009 00:35:43 -0500 [thread overview]
Message-ID: <4AFE41AF.8050802@fastmail.fm> (raw)
In-Reply-To: <20091114081040.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> 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
next prev parent reply other threads:[~2009-11-14 5:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-12 19:46 Add branch management for releases to gitworkflows rocketraman
2009-11-12 19:46 ` [PATCHv3] " rocketraman
2009-11-12 20:08 ` skillzero
2009-11-12 20:30 ` Raman Gupta
2009-11-13 22:19 ` Nanako Shiraishi
2009-11-13 22:56 ` Raman Gupta
2009-11-13 23:10 ` Nanako Shiraishi
2009-11-14 5:35 ` Raman Gupta [this message]
2009-11-14 8:59 ` Björn Gustavsson
2009-11-14 9:01 ` Nanako Shiraishi
2009-11-14 17:27 ` Raman Gupta
2009-11-15 9:14 ` Junio C Hamano
2009-11-15 17:07 ` Thomas Rast
2009-11-18 0:19 ` Raman Gupta
2009-11-18 14:59 ` Thomas Rast
2009-11-19 4:11 ` Nanako Shiraishi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AFE41AF.8050802@fastmail.fm \
--to=rocketraman@fastmail.fm \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=nanako3@lavabit.com \
--cc=trast@student.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.