On Mon, Feb 15 2021, Taylor Blau wrote:
> On Thu, Feb 11, 2021 at 08:33:14PM +0100, SZEDER Gábor wrote:
>> > +--preferred-pack=<pack>::
>> > + When using the `write` subcommand, optionally specify the
>> > + tie-breaking pack used when multiple packs contain the same
>> > + object. Incompatible with other subcommands, including `repack`,
>>
>> I think this shouldn't be an option of the 'git multi-pack-index'
>> command but an option of its 'write' subcommand.
>
> :-/. I wrote a lengthy response on Friday, but Gmail must have eaten it.
>
> The gist of my response was that the intermingling of sub-commands with
> options from other sub-commands goes deeper than just the documentation,
> since command-line arguments are only parsed once in
> builtin/multi-pack-index.c.
>
> I explored whether or not it would be worth it to parse the common
> options first, and then have separate options for each of the
> sub-commands (as is done in the commit-graph builtin). But, this is
> tricky, since we accept common options on either side of the sub-command
> (i.e., we'd expect both 'git multi-pack-index --object-dir=... write' to
> behave the same as 'git multi-pack-index write --object-dir=...').
>
> So you could let the first call to parse_options() parse all of the
> arguments, but then specialized arguments (e.g., 'repack --batch-size')
> would cause the parse-options API to barf because the first call to
> parse_options() doesn't recognize '--batch-size'.
>
> I think the easiest way to do it would be to pass
> PARSE_OPT_STOP_AT_NON_OPTION, and then let the subsequent calls to
> parse_options() pass an array of option structs that also includes the
> common options so they can be parsed on either side of the sub-command.
>
> Obviously this leads to a lot of rather unfortunate duplication. So,
> I'm content to leave it all as-is, and let the multi-pack-index
> builtin check the disallowed combinations itself (e.g., if you passed
> '--preferred-pack' but aren't in 'write' mode, then we should complain).
>
> I can certainly move this piece of documentation into the 'write'
> section, though, which should alleviate your immediate concern.
I may be missing something, but...
It sounds to me like you're imagining this is more complex than it is
because you don't know about some/all of parse_options_concat() or
PARSE_OPT_KEEP_*.
See e.g. cmd_{switch,restore} in builti/checkout.c, or the entire family
of diff-like commands where we do parse_options() followed by
setup_revisions(). We've got a lot of commands that parse options in a
piecemeal manner.
At no point do you need to re-parse the options. You just have the
common command parse as far as it gets, and leave anything else in
argv/argc for sub-commands like "write".
I think the problem is you read the builtin/commit-graph.c code, it
could really benefit from using parse_options_concat(), now things like
"object-directory" are copy/pasted in that file. See 2087182272
(checkout: split options[] array in three pieces, 2019-03-29) for a
commit which simplified that sort of code.
In this case you'd share the "opts_multi_pack_index" struct between the
various commands, it would just have unused fields for "write" that
aren't used by "verify" or whatever.
The PARSE_OPT_STOP_AT_NON_OPTION flag isn't for what you're doing with
"write" here, since as your test shows you're doing:
git multi-pack-index <ALL_OPTS> <SUBCOMMAND>
But PARSE_OPT_STOP_AT_NON_OPTION is for cases like "git-remote" that do:
git multi-pack-index <COMMOT_OPTS> <SUBCOMMAND> <SUBCOMMAND_OPTS>
(Or maybe you really want the latter, and the test change isn't
representative).
So then we want to stop at the first non-option, i.e. the subcommand. I
think it's good practice not to emulate how "git remote" works for new
commands, which makes things a bit simpler to implement.
You say "since we accept common options on either side of the
sub-command" but without PARSE_OPT_STOP_AT_NON_OPTION this works, since
if you can parse everything you'll have "write" left, but if you truly
have unknown options you'll have more than that in argv.
All of the above shouldn't be taken as a "your patch should change"
comment, maybe it's fine as-is.
I just replied because it sounded like you didn't spot how to easily use
parse_options() to do this sort of thing. It's actually rather easy.
