Re: [Monotone-devel] overwriteable and negatable options

[Stephen Leake]

Timothy Brownawell <address@hidden> writes:

> On 06/21/2010 02:43 PM, Stephen Leake wrote:
>> In the particular case of dates, I don't think we need
>> --no-format-dates; that's the same as --default-date-format.
>
> --no-format-dates tells it not to do any formatting;

not really; dates are written to strings by formatting. It says use
the hardcoded (not specified by the hook) default format.

> --default-date-format tells it to ask the hook what format to use.

Ah, that is different.

> But the hook and any default options are probably being defined by the
> same person, so --default-date-format is probably silly and it can go
> away.

I think it would be better to make --default-date-format mean what
--no-date-format means now, and drop --no-date-format.

Although maybe --internal-date-format would be a better name, since in
general we want 'default' to mean 'what you specified in a hook'.

>> How many other options actually have a group reset, as opposed to a
>> single reset? I don't see any in options.hh, but maybe I missed
>> something.
>
> --verbosity and friends kinda-sorta do, but that probably doesn't
> count (hm, this actually doesn't need a resetter, it would do the same
> thing as "--verbosity=0").

Yes, it's not very clear that '--no-verbose' means 'undo --quiet'.

And there is currently no way for the help system to know that --full is
part of that group.

It would be nice if the help system always grouped these together.  But
that turns out to be hard, so relying on the descriptions to relate the
groups will have to be enough.

> --bind belongs with --no-transport-auth and --stdio in a way that a
> group reset *might* make sense, except that --no-transport-auth and
> --stdio are really only for self-invocation (and probably should be
> hidden).

I agree these should be hidden.

> --conflicts-file, --resolve-conflicts, and --resolve-conflicts-file
> look like they go together.... 

Yes, although they are used on different commands; --conflicts-file on
'conflicts', and '--resolve-conflicts-file' on 'merge' and similar. But
that's true of many options.

> looks like --conflicts-file and --resolve-conflicts-file really ought
> to be the same option, and
> --resolve-conflicts/--resolve-conflicts-file would make sense having a
> common reset option.

yes.

> This last one looks like the *only* case where we really need a group
> of options to get reset together. 

Ok, thanks for this analysis.

> And I suppose even this could be recast as a pair of
> somewhat-independent options, where
> --resolve-conflicts/--no-resolve-conflicts turn conflict handling on
> or off and --resolve-conflicts-file tells it to use something other
> than the default location if conflict handling is turned on (and of
> course also switches handling to on, since doing otherwise would be
> odd). 

Yes.

> Really this would just take a bit of tweaking in the descriptions:
>>   --resolve-conflicts             resolve conflicts interactively (???)

--resolve-conflicts means resolve conflicts _non_-interactively.

Perhaps:

--resolve-conflicts             specify conflict resolutions in a file

> So [0] (current format) is actually workable, and I think I can set it
> to I() on startup if you try to give a resetter for an optset that has
> more than one flag.

Ok.

Then optset is only for grouping, which is good. Doesn't that mean the
resetter can be associated with the option, not the optset? In case in
the future we come up with two options in the same group that want to
have separate resetters. That could be handled with
GROUPED_SIMPLE_OPTION, but that introduces an unnecessary optset.

-- 
-- Stephe