On Fri, Sep 10 2021, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>> Let's "fix" various "git <cmd> -h" output by "properly" aligning the
>> output in cases where we continue usage output after a "\n". The "fix"
>> and "properly" scare quotes are because this actually makes things
>
> The "A" and "B" *in* scare quotes?
Perhaps I should take a stab at rewriting this, something like:
Let's start by aligning the strings in the C code so that their
indentation is correct, in the end it'll still be off due to the
indentation parse_options() itself adds, but that'll be fixed in a
subsequent commit. That subsequent commit relies on the indentation
in the source being consistent.
>> The issue is that we should have whitespace corresponding to the
>> length of the command name here, e.g. in the case of "git ls-remote"
>> it should be 14 characters, or the length of ""git ls-remote
>> ". Instead we had 21 characters in builtin/ls-remote.c, those extra 7
>> characters are the length of "usage: " (and also " or:"). So in the C
>> locale the resulting output aligns nicely:
>>
>> $ git ls-remote -h
>> usage: git ls-remote [--heads] [--tags] [--refs] [--upload-pack=<exec>]
>> [-q | --quiet] [--exit-code] [--get-url]
>> [--symref] [<repository> [<refs>...]]
>
> Isn't this aiming for a wrong end goal? With an overly long
> subcommand name, we'd end up with overly deep indentation of the
> subsequent lines (hence too narrow a space to fit the options).
>
> Rather, wouldn't it be better to aim for a consistent and wide
> enough indentation, like say two tabs, everywhere, no matter how
> long the subcommand name is?
Similarly to the discussion on another patch about whether we should
convert these long lines to [<options>] or not, I think this is really
outside the scope of this series.
In this particular case the indentation remains exactly the same before
this series and after, for the other cases there's usually a change of
1-3 spaces or so, i.e. they were slightly off.
Should we have no indentation at all? Auto re-indent or whatever? Maybe,
but let's start by narrowly fixing code that's clearly a bit off in
functionality from what it's doing & intending to do right now.
