Re: [PATCH v7 1/5] command-list.txt: prepare with [commands] header

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v7 1/5] command-list.txt: prepare with [commands] header

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:04:47

Sébastien Guimmara  [off-list ref] writes:
quoted
This is largely just a "taste" thing, but with all these backslashes
in the supporting infrastructure you had to add in Makefiles and
scripts, don't you think the choice of the way you designed the
format to use '[commands]' was a rather poor one?  After all, all
you need is a clear separator line for a block of commands and
another block of groups, and there wasn't a reason why you needed to
use square brackets for that, and the sed scripts are suffering from
that poor choice.

You could for example have used the existing "# List of known git
commands" as such a signal to tell that all the no comment lines
below are commands.
I tend to think that relying on comments as marks for parsers is brittle,
but indeed square brackets get in the way of sed regexes. I'll think of
something better. Thanks.
Heh, we, and more importantly our users, already rely on a marker in
comments when writing their commit log messages ;-)

I would not be opposed to a new header that is outside comment, but
I do not think the marker line that is also a comment is "brittle"
and would not be opposed to that, either.

    # do not molest the next line
    ### command list
    # name category
    git-add mainporcelain
    ...

would be perfectly acceptable.

I was just pointing out that you did not even have to have patch
1/5.

Thanks.

Re: [PATCH v7 1/5] command-list.txt: prepare with [commands] header

From: Eric Sunshine <hidden>
Date: 2016-06-15 23:04:47

On Fri, May 15, 2015 at 4:44 PM, Junio C Hamano [off-list ref] wrote:
Sébastien Guimmara  [off-list ref] writes:
quoted
quoted
You could for example have used the existing "# List of known git
commands" as such a signal to tell that all the no comment lines
below are commands.
I tend to think that relying on comments as marks for parsers is brittle,
but indeed square brackets get in the way of sed regexes. I'll think of
something better. Thanks.
Heh, we, and more importantly our users, already rely on a marker in
comments when writing their commit log messages ;-)

I would not be opposed to a new header that is outside comment, but
I do not think the marker line that is also a comment is "brittle"
and would not be opposed to that, either.

    # do not molest the next line
    ### command list
    # name category
    git-add mainporcelain
    ...

would be perfectly acceptable.

I was just pointing out that you did not even have to have patch
1/5.
Is that entirely accurate? The machinery (Makefiles, cmd-list.perl)
does have to be updated at some point to skip the "common" block which
get added in patch 2/5. That work could be done as part of patch 2/5,
though it seemed cleaner to me to make it separate (though I don't
care too strongly).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help