git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 0/3] git help: group common commands by theme
Date: Wed, 6 May 2015 16:49:59 -0400	[thread overview]
Message-ID: <CAPig+cTztwF-pYGjEpjDzxTJSXQBJFcp_F924htx5fHT01mcKQ@mail.gmail.com> (raw)
In-Reply-To: <554A78EE.1040002@gmail.com>

On Wed, May 6, 2015 at 4:26 PM, Sébastien Guimmara
<sebastien.guimmara@gmail.com> wrote:
> On 05/06/2015 05:08 AM, Eric Sunshine wrote:
>> On Mon, May 4, 2015 at 4:28 PM, Sébastien Guimmara
>> <sebastien.guimmara@gmail.com> wrote:
>>> - Add a [groups] block containing names and description for groups:
>>>
>>>     [groups]
>>>     init                   starting a working area
>>>
>>> - Add a [commands] header on top of the known command list, and
>>>    group names as a third column.
>>>
>>>     [commands]
>>>     git-add            mainporcelain                common-worktree
>>
>> Thanks, this version is looking better. I, personally, still find the
>> redundant "command-" prefix ugly and would just as soon see it go
>> away. I'll make some suggestions about that when reviewing patch 2/3.
>
> Indeed, I'm a bit annoyed by this prefix. We could do two things:
> - either drop the [deprecated] options, since it's never used.
> - or keep it, but make it exclusive with [common]. It makes sense after
>   all that if a command is deprecated, we don't want to consider it
>   common anymore.
>
> In both cases, we end up with only three columns, the third being
> optional.
>
> The common- prefix can then be removed in favor of the group ID alone.

Sorry for not yet reviewing patch 2/3. I'm trying to find time to
review it and make the promised suggestions, however, Real Life keeps
getting in the way. If 'deprecated' has never been used and if it is
not likely to be used in the future, then dropping that column may
indeed be an easy way forward toward the goal of eliminating the
"common-" prefix. A possible shortcoming of this columnar approach,
however, is that if someone someday comes up with some new type of
attribute to assign in a new column, then you still end up in the same
boat where not all entries use all columns, and you have difficulty
figuring out to which column an attribute belongs.

Instead, as mentioned originally, I had envisioned a solution in which
any command tagged with an attribute mentioned in [groups] would be
considered common, without having to resort to a prefix or fixed
columns. This should be more flexible in the long run, but may be
overkill for present day. I think that awk should be able to handle
this easily, but haven't had the time to actually sit down and flesh
it out (which I wanted to do while reviewing 2/3).

And, any solution is likely going to have to take into account the two
Makefiles Junio mentioned.

  reply	other threads:[~2015-05-06 20:50 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-04 20:28 [PATCH 0/3] git help: group common commands by theme Sébastien Guimmara
2015-05-04 20:28 ` [PATCH 1/3] command-list.txt: " Sébastien Guimmara
2015-05-06  6:57   ` Eric Sunshine
2015-05-06 20:58     ` Sébastien Guimmara
2015-05-07 16:50       ` Eric Sunshine
2015-05-07 19:23         ` Johannes Sixt
2015-05-08 10:11           ` Johannes Schindelin
2015-05-08 12:01             ` Andreas Schwab
2015-05-08 13:02               ` Johannes Schindelin
2015-05-08 18:43         ` Sébastien Guimmara
2015-05-08 19:00           ` Eric Sunshine
2015-05-04 20:28 ` [PATCH 2/3] generate-cmdlist.sh: parse common group commands Sébastien Guimmara
2015-05-08  3:20   ` Eric Sunshine
2015-05-08  3:39     ` Eric Sunshine
2015-05-08 20:55     ` Sébastien Guimmara
2015-05-04 20:28 ` [PATCH 3/3] git help: group common commands by theme Sébastien Guimmara
2015-05-06  3:16   ` Eric Sunshine
2015-05-06 20:31     ` Sébastien Guimmara
2015-05-08 21:08     ` Sébastien Guimmara
2015-05-08 21:17       ` Stefan Beller
2015-05-08 21:19         ` Eric Sunshine
2015-05-08 21:20         ` Sébastien Guimmara
2015-05-06  3:08 ` [PATCH 0/3] " Eric Sunshine
2015-05-06 20:26   ` Sébastien Guimmara
2015-05-06 20:49     ` Eric Sunshine [this message]
2015-05-06  3:41 ` Junio C Hamano
2015-05-08 18:00   ` Sébastien Guimmara
2015-05-08 18:53     ` Junio C Hamano
2015-05-06  7:59 ` Matthieu Moy
2015-05-06 17:42   ` Junio C Hamano
2015-05-07  8:42     ` Matthieu Moy
2015-05-07 18:44       ` Junio C Hamano
2015-05-08  8:18         ` Matthieu Moy
2015-05-08 16:19           ` Junio C Hamano
2015-05-07  9:31 ` Emma Jane Hogbin Westby
2015-05-08 18:21   ` Sébastien Guimmara
2015-05-08 18:58     ` Junio C Hamano
2015-05-08 20:08       ` Sébastien Guimmara
  -- strict thread matches above, loose matches on Subject: below --
2015-05-01 14:51 Sébastien Guimmara

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+cTztwF-pYGjEpjDzxTJSXQBJFcp_F924htx5fHT01mcKQ@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).