Re: Bug report: git clone with dest

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 5, 2018, 22:37 UTC
Message-ID: <xmqq4lo0aq56.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20180105205227.GA6958@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 17 quoted lines

> On Fri, Jan 05, 2018 at 12:45:03PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > Out of curiosity, did this change at some point? I thought the process
>> > used to be to merge to maint, and then pick up topics in master by
>> > merging maint to master.
>> 
>> If you look at "Sync with maint" merges made to 'master', you'd
>> notice that most of them are only updating Documentation/RelNotes/*
>> and otherwise no-effect merges, simply because when such an up-merge
>> is made, everything in 'maint' is already in 'master' because topics
>> are merged to the latter first.  Security fixes that go through
>> embargoes are excempt for obvious reasons ;-)
>
> OK, that makes sense. Pretty sure I did it wrong when I was interim
> maintainer back in the day, then. :)

Well, MaintNotes on the 'todo' branch needs a bit of updating, as it says something somewhat misleading.

-- >8 --
Subject: MaintNotes: clarify the purpose of maint->master upmerge

Even though the paragraph before this one is pretty clear that topics are first merged to 'master' and then to 'maint', it was misleading to say 'maint' is merged to 'master' to propagate fixes forward, as most of the time, such an upmerge is a noop because topics merged to 'maint' are usually merged to 'master' already.

These up-merges are done primarily to make sure that the tip of 'master' has updated release notes from all the maintenance tracks, so be explicit about that to avoid confusion.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 MaintNotes | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MaintNotes b/MaintNotes
index 3a70b88..393d81f 100644
--- a/MaintNotes
+++ b/MaintNotes
@@ -173,8 +173,8 @@ feature release).  These days, maintenance releases are named by
 incrementing the last digit of three-dotted decimal name (e.g. "2.12.1"
 was the first maintenance release for the "2.12" series).
 
-New features never go to the 'maint' branch.  This branch is also
-merged into "master" to propagate the fixes forward as needed.
+New features never go to the 'maint' branch.  It is merged into "master"
+primarily to propagate the description in the release notes forward.
 
 A new development does not usually happen on "master". When you send a
 series of patches, after review on the mailing list, a separate topic