[PATCH v5 0/4] parse-options: properly align continued usage output

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.