Is there a recommendation for generating Git-style, 'last one wins' flags like --progress/--no-progress?

[vermiculus]

I cursory search of the Arg struct documentation for no- yields nothing to do this automatically.

Given this documentation from conflicts_with, though, what I'm asking for might not be exactly possible with clap:

NOTE: All arguments implicitly conflict with themselves.

This would seem to imply the set/reset behavior seen in some Git commands isn't possible, but I'm also wondering if there's a way to have two options control a single field with ArgAction::SetTrue and ArgAction::SetFalse, respectively.

[epage]

You want to declare that the arts override each other.

[epage]

btw we have a cookbook entries for CLIs, including git, as a way of allowing people to discover how to implement different patterns based off of their familiarity with different commands. If you want to extend it to cover this pattern, feel free!

[vermiculus]

This works functionally (thanks!) but help text is a little wonky. As the style often used in Git's docs, the goal would be something like this:

Usage: git my-tool [OPTIONS]

Options:
      --[no-]do-thing     Do it
  -h                      Show quick help

Reading through clap's code, I don't think this is possible. Implementing a manual override for how the option displays in -h seems like a Bad Idea™ given the potential for abuse.

The best I can get is this without doing something too weird is this:

Usage: git my-tool [OPTIONS]

Options:
      --do-thing     
      --no-do-thing  Do it
  -h                 Show quick help

using

#[derive(Debug, clap::Parser)]
pub struct Args {
    #[arg(long)]
    do_thing: bool,
    /// Do the thing
    #[arg(long, overrides_with = "do_thing")]
    no_do_thing: bool,
}

which, admittedly, is also a pattern used consistently in Git's docs, but has a couple of weird side-effects:

• There's no docstring on do_thing and the docstring for no_do_thing is wrong. This can be mitigated with #[arg(help = ...)].
• If next_line_help is used on no_do_thing, there's an undesirable blank line after --do-thing. There doesn't seem to be a way to remove this.

I could simplify the help text by just hiding --no-do-thing entirely, but that seems awkward in that it hides the option.

I can submit a PR to add the above pattern to the Git cookbook, but I wonder what your thoughts are on an Arg.bool_style: ArgBoolStyle where

• ArgBoolStyle::Presence is the present/not-present logic (currently field: bool)
• ArgBoolStyle::Value is (I think; I need to test this again) the --flag=<true|false> behavior (currently field: Option<bool>)
• ArgBoolStyle::OptionalValue is the --flag[=<true|false>] behavior (currently field: Option<Option<bool>>)
• ArgBoolStyle::Override is this --flag / --no-flag style (no satisfying ways to implement this today)

(specific value names TBD, obviously)

To do this right might be a pretty meaty PR, so I wanted to get your thoughts on direction before going further. Some of these would require validation with the field type and possibly have interactions with Arg.default_value.

[vermiculus]

(I think in the short-term, I will solve my immediate problem with help_template or similar.)

[epage]

#815 explores this somewhat (but is working on the base assumption of completely baking in the whole negation functionality)

In my applications, I've set hide = true for the default cases.

I can submit a PR to add the above pattern to the Git cookbook, but I wonder what your thoughts are on an Arg.bool_style: ArgBoolStyle where

As you called out, we have ways of building up these different arg types using existing mechanisms. These work out well because they build on core principles that people can use to make CLIs do many other things. The main hole is automatic negation. This is admittedly a pretty difficult one because

• clap assumes there is one argument per destination (unless its an alias), see also Support multiple arguments writing to the same destination #3146
• clap assumes a 1:1 between argument and help