Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> Now that mktag has been migrated to use the fsck machinery to check
> its input, it makes sense to teach it to run in the equivalent of "git
> fsck"'s default mode, instead of hardcoding "git fsck --strict". Let's
> do that and support the "--no-strict" option.
>
> Since this is a new option we don't need to cater to parse-option.c's
> default of automatically supporting --strict. So let's use
> PARSE_OPT_NONEG, using a new trivial helper macro.
I do not understand the last paragraph.
git mktag --no-strict --strict --no-strict
should follow the usual "the last one wins" rule, so I would say
that supporting "--strict", whether it is done automatically as a
natural consequence of use of parse-options or not, would be a good
thing (also I so not see PARSE_OPT_NONEG in this patch). Perhaps
the log message (and the title) needs updating?
mktag: add a --[no-]strict option
Now that mktag has been migrated to use the fsck machinery to
check its input, it makes sense to teach it to run in the
equivalent of "git fsck"'s default mode. For cases where mktag
is used to (re)create a tag object using data from an existing
and malformed tag object, the validation may optionally have to
be loosened. Teach the command to take the "--[no-]strict"
option to do so.
or something?
