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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Raman Gupta <rocketraman@xxxxxxxxxxx> writes:

> Nanako Shiraishi wrote:
>> Quoting rocketraman@xxxxxxxxxxx:
>> 
>>> + - 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 ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux