From: Eric Sunshine <sunshine@sunshineco.com>
To: "Sébastien Guimmara" <sebastien.guimmara@gmail.com>
Cc: Git List <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v10 1/5] command-list: prepare machinery for upcoming "common groups" section
Date: Thu, 21 May 2015 10:16:02 -0400 [thread overview]
Message-ID: <CAPig+cSegd8P5vFAmmLNU_YDTuk6HXqoGtEi2qUTR+61vDv3ww@mail.gmail.com> (raw)
In-Reply-To: <555DE3DB.1000406@gmail.com>
On Thu, May 21, 2015 at 9:55 AM, Sébastien Guimmara
<sebastien.guimmara@gmail.com> wrote:
> On 05/21/2015 03:48 PM, Eric Sunshine wrote:
>> On Thu, May 21, 2015 at 9:13 AM, Sébastien Guimmara
>> <sebastien.guimmara@gmail.com> wrote:
>>> The ultimate goal is for "git help" to classify common commands by
>>> group. Toward this end, a subsequent patch will add a new "common
>>> groups" section to command-list.txt preceding the actual command list.
>>> As preparation, teach existing command-list.txt parsing machinery, which
>>> doesn't care about grouping, to skip over this upcoming "common groups"
>>> section.
>>>
>>> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
>>> Signed-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com>
>>> ---
>>> @@ -95,7 +95,9 @@ your language, document it in the INSTALL file.
>>> that categorizes commands by type, so they can be listed in appropriate
>>> subsections in the documentation's summary command list. Add an entry
>>> for yours. To understand the categories, look at git-commands.txt
>>> -in the main directory.
>>> +in the main directory. If the new command is part of the typical Git
>>> +workflow and you believe it common enough to be mentioned in 'git help',
>>> +map this command to a common group in the column [common].
>>
>> I think you meant to squash the documentation update into patch 2/5
>> where the "common groups" block is actually introduced. It doesn't
>> really belong in this patch which is about updating machinery in
>> preparation for the new block.
>
> I don't mind squashing it with another commit, but in this case, wouldn't it
> make more sense to squash it with 4/5, when the 'common' tag is removed and
> the file is in its final form ?
In my mind, the most logical point at which the documentation should
start talking about the new "common coups" is when "common groups"
actually comes into existence since the new documentation is directly
related to birth of that new section of the file. The documentation
update is, at best, only very peripherally related to removal of the
old 'common' tag, so it doesn't really seem logical to tie the
documentation update to 'common' removal in 4/5. But that's just my
opinion...
>> Also, it's now spelled "### common groups" rather than "[common]".
>
> actually, this [common] is not the one I added in a previous series,
> but the one that was already present:
>
> # command name category [deprecated] [common]
Ah, right. Thanks for clarifying.
next prev parent reply other threads:[~2015-05-21 14:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-21 13:13 [PATCH v10 0/5] group common commands by theme Sébastien Guimmara
2015-05-21 13:13 ` [PATCH v10 1/5] command-list: prepare machinery for upcoming "common groups" section Sébastien Guimmara
2015-05-21 13:48 ` Eric Sunshine
2015-05-21 13:55 ` Sébastien Guimmara
2015-05-21 14:16 ` Eric Sunshine [this message]
2015-05-21 13:13 ` [PATCH v10 2/5] command-list.txt: add the common groups block Sébastien Guimmara
2015-05-21 13:13 ` [PATCH v10 3/5] generate-cmdlist: parse common group commands Sébastien Guimmara
2015-05-21 13:13 ` [PATCH v10 4/5] command-list.txt: drop the "common" tag Sébastien Guimmara
2015-05-21 13:13 ` [PATCH v10 5/5] help: respect new common command grouping Sébastien Guimmara
2015-05-21 14:29 ` Eric Sunshine
2015-05-21 16:16 ` Junio C Hamano
2015-05-21 16:46 ` Eric Sunshine
2015-05-21 17:15 ` Junio C Hamano
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=CAPig+cSegd8P5vFAmmLNU_YDTuk6HXqoGtEi2qUTR+61vDv3ww@mail.gmail.com \
--to=sunshine@sunshineco.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sebastien.guimmara@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).