Re: [PATCH 1/2] Add feature release instructions to MaintNotes addendum

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 26, 2009, 20:28 UTC
Message-ID: <7vprg4m3k9.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <49CB8871.2020605@fastmail.fm>

Raman Gupta <rocketraman@fastmail.fm> writes:

Show 20 quoted lines

> Nanako Shiraishi wrote:
>> Quoting rocketraman@fastmail.fm:
>> 
>>> + - The 'maint' branch is updated to the new release.
>>> +
>>> +     $ git checkout maint
>>> +     $ git merge master
>>> +
>>> +   This is equivalent to deleting maint and recreating it from
>>> +   master, but it preserves the maint reflog.
>> 
>> After giving a recipe that is better than an alternative, what's
>> the point of describing an inferior alternative as "equivalent",
>> when it is obviously not "equivalent"?
>
> Is this better:
>
> The resulting maint tree is equivalent to deleting maint and
> recreating it from the tip of master, but merging from master
> preserves the maint reflog.

It is unclear what you are trying to explain with these two (in your original) or three (your rewrite) lines. As an explanation for the two command sequence, I would expect to see:

    "This merges the tip of the master into maint".

But that is literally what the command sequence does, so it goes without saying.

If there is anything that needs to be said further, I think it is not how delete-then-recreate is inappropriate (I do not think it is even worth teaching). But you may want to explain the reason _why_ maint gets this update from master. I thought the explanation "... is updated to the new release" already covers that motivation, but if you want to make the description really novice-friendly, you _could_ say something like:

    Now a new release X.Y.Z is out, the 'maint' branch will be used to
    manage the fixes to it.  The branch used to be used for managing the
    fixes to X.Y.(Z-1), and does not have any feature development that
    happened between X.Y.(Z-1) and X.Y.Z.  Because these changes are
    contained in the 'master' branch, we can merge 'master' to 'maint' to
    have the latter have them, which prepares it to be used for managing
    the fixes to X.Y.Z.

I personally would not want to see somebody who needs the above to be explained to take over git maintenance after I get hit by a wayward bus, by the way ;-)