This series changes usage_with_options_internal() in parse-options.c to properly align continued "\n" usage output. There's only a very small typo changes in this v5 in response to https://lore.kernel.org/git/xmqq8s01geov.fsf@gitster.g/; I also re-read the rest over & spellchecked the comments I added, for whatever that's worth. I didn't add a test in t/helper/ as Junio suggested, since it's the usage message itself it doesn't slot nicely into the control flow of t/helper/test-run-command.c, we could of course make it work, but I'd prefer to punt on it. I think having manually tested the output should do in this case. I.e. I manually looked at all the "-h" emitted by t0012-help.sh and it's all nicely formatted now (aside from some overly long lines, addressing that is left for another day). Ævar Arnfjörð Bjarmason (4): parse-options API users: align usage output in C-strings send-pack: properly use parse_options() API for usage string git rev-parse --parseopt tests: add more usagestr tests parse-options: properly align continued usage output Documentation/git-send-pack.txt | 4 +- builtin/ls-remote.c | 4 +- builtin/send-pack.c | 8 ++-- builtin/show-branch.c | 6 +-- builtin/stash.c | 2 +- builtin/tag.c | 4 +- parse-options.c | 76 +++++++++++++++++++++++++++------ t/t1502-rev-parse-parseopt.sh | 54 +++++++++++++++++++++++ 8 files changed, 132 insertions(+), 26 deletions(-) Range-diff against v4: 1: 64d8647340d = 1: 352662be92d parse-options API users: align usage output in C-strings 2: f10ff775c69 = 2: d3767214d22 send-pack: properly use parse_options() API for usage string 3: 05a0c7cac37 = 3: 8262999b456 git rev-parse --parseopt tests: add more usagestr tests 4: 55480dee680 ! 4: 9f7f3f8b4ed parse-options: properly align continued usage output @@ Commit message But to do that we'll need to find the length of "git stash". We can discover that from the "cmd" in the "struct cmd_struct", but there - might cases with sub-commands or "git" itself taking arguments that + might be cases with sub-commands or "git" itself taking arguments that would make that non-trivial. - Even if it was I still think this approach is better, because this way + Even if it were I still think this approach is better, because this way we'll get the same legible alignment in the C code. The fact that usage_with_options_internal() is adding its own prefix padding is an implementation detail that callers shouldn't need to worry about. -- 2.33.0.1098.gf02a64c1a2d
