"Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> - if (regex_) {
> + if (regex_ && (flags & CONFIG_FLAGS_FIXED_VALUE))
> + value_regex = regex_;
> + else if (regex_) {
> if (regex_[0] == '!') {
> do_not_match = 1;
> regex_++;
When the --fixed-value option is in effect, there is no way to say
"replace values that do not match this string", because unlike the
regex case, we do not special case '!' at the beginning.
I think it is a good design decision. The special case has an
escape hatch to start your value_regex with "[!]" when ERE is in
use, but there is no such escape hatch possible with --fixed-value.
Depending on how this '!' negation is documented to the end-users
for existing value_regex that is ERE, the documentation for the new
option may want to talk about the lack of negation explicitly.
... goes and looks ...
It is worse than I thought. Here is what "git config" description
has (and some of the badness is not the fault of this series):
Multiple lines can be added to an option by using the `--add` option.
If you want to update or unset an option which can occur on multiple
lines, a POSIX regexp `value_regex` needs to be given. Only the
existing values that match the regexp are updated or unset. If
you want to handle the lines that do *not* match the regex, just
prepend a single exclamation mark in front (see also <<EXAMPLES>>).
The end-users these days no longer see "lines" because they do not
hand edit .git/config, so we may need a replacement phrase to refer
to a single "vari.able=value" setting, but we should leave it out of
the scope of this series to clean that up---"git config --help" is
full of references to "line".
It was not "a POSIX regexp" (which does not say if it is BRE or
ERE), and it no longer is a regexp with the new option.
... which can occur on multiple lines, a pattern `value_regex`
needs to be given. Only the existing values that match the
pattern are updated or unset. The pattern is by default matched
as an extended regular expression, but with the `--fixed-value`
option, taken as a literal string and values must be identical
to it to be considered a match. You can prepend an exclamation
point '!' to affect lines that do *not* match the pattern, but
this is applicable only when not using the `--fixed-value`
option.
Ideally we probably should do s/value_regex/value_pattern/ in the
documentation and error messages eventually, but I do not know if
it is warranted in the scope of this series.
