From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 01 May 2015 16:29:50 GMT
Subject: Re: Patch that modifies git usage message
Message-ID: <xmqqfv7gxnup.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAGZ79kY1ZoYrVwVVqfyB+uMGsJo59qDxbDLgyo5qygSm=CUVhA@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

> For the patch itself:
>
> $ grep -r usage *.c builtin/*.c |wc -l
> 551
> $ grep -r Usage *.c builtin/*.c |wc -l
> 3
>
> The community agreed (maybe subconciously) to prefer lower case
> for the 'usage' string, so I don't think this is an improvement.

I tend to agree with the conclusion, but you need to be a bit
careful here.  These catch all the variable names that contain
"[uU]sage" as substring, but we do not spell in-code variables
with camelCase, so the former probably is over-counting.  Things
like "static const char usage[] = ..." are counted; so are calls
to usage_with_options().

If you look for the beginning of a string constant, you would get
this:

    $ git grep '"usage' -- \*.c builtin/\*.c
    12
    $ git grep '"Usage' -- \*.c builtin/\*.c
    0

The former undercounts the messages because many usage messages are
produced by calling usage_with_options() these days.

The latter being zero made me scratch my head and do this:

    $ git grep Usage -- \*.c builtin/\*.c
    commit.c: * Usage example:
    test-hashmap.c: * Usage: time echo "perfhas...

I cannot find the third one you found for "Usage" in your example,
though.