Æ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? > 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? Thanks.
