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/ (local); 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