Re: [PATCH 00/10] Docs: git tag

From: Michael Witten <mfwitten@gmail.com>
Date: Mar 29, 2011, 13:59 UTC
Message-ID: <AANLkTi=U8amjCM7=bn2=ewJs2UpNG+D+sCKm4pPf4hP-@mail.gmail.com>
In-Reply-To: <4D917B5E.1000600@drmicha.warpmail.net>

On Tue, Mar 29, 2011 at 01:25, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Show 26 quoted lines

> Junio C Hamano venit, vidit, dixit 28.03.2011 20:04:
>> Michael Witten <mfwitten@gmail.com> writes:
>>
>>> Small patches fixing up the `git tag' docs.
>>>
>>> Michael Witten (10):
>>>   Docs: git tag: Add `the'
>>>   Docs: git tag: peoples back -> people's backs
>>>   Docs: git tag: Revise a paragraph.
>>>   Docs: git tag: other's -> the other person's
>>>   Docs: git tag: Streamline a sentence.
>>>   Docs: git tag: Add missing 'the'
>>>   Docs: git tag: Use 'who' again
>>>   Docs: git tag: Remove superfluous 'with'
>>>   Docs: git tag: Use semicolon
>>>   Docs: git tag: Rewrite discussion of GIT_COMMITTER_DATE
>>
>> Thanks; all looked sensible changes, except for 7/10 which I somehow find
>> the original is more readable than the new text, partly because the
>> sentences are shorter but more importantly because the two sentences make
>> two separate assertions (the first is about what "one-shot" pull means,
>> the second is about why automatic tag following is not desired in that
>> situation).
>
> Looked mostly sensible to me (and I share Junio's view on 7), too,
> although I probably would have changed "other's" simply to "others'".

I probably chose the singular variant for 2 reasons: I generally prefer singular renditions, and the sentence is referring to an example of a pull-request from one individual.

On Tue, Mar 29, 2011 at 01:25, Michael J Gruber <git@drmicha.warpmail.net> wrote:

> Those 10 patches could have been 1 actually, they are really divided
> into atoms (which is not bad per se) even though they all fall under
> "cosmetic language corrections and improvements" without any content
> change nor restructuring.

It's always hard to tell what delineations will be appreciated. However, it's almost always the case that the smaller a patch is, the more quickly it can be reviewed and approved (also, the smaller the diff, the more meaningful the commit message), so I err on the side of too small; after all, it's generally much easier to squash than to split.

Of course, I would have no problem if Junio ultimately saw fit to squash some or all of them (with a note that such squashing has occurred).

Thanks for your input.