[BUG?] "git config --replace-all key value value_regex" ignores value_regex?

As discussed [1], I am working on relaxing the "regex" part of the value_regex parameter in the "git config" command.

[1] https://lore.kernel.org/git/xmqqlfez6alb.fsf@gitster.c.googlers.com/

As I am working to solidify how this command works, I'm adding tests for all of the compatible options that could use a "--literal-value" modifier. One that seemed helpful to use was "--replace-all". The docs have this line in the SYNOPSIS:

'git config' [<file-option>] [--type=<type>] [--literal-value] --replace-all name value [value_regex]

and this in the OPTIONS:

--replace-all::
	Default behavior is to replace at most one line. This replaces
	all lines matching the key (and optionally the value_regex).

However, this test fails:

test_expect_success '--replace-all and value_regex' '
	q_to_tab >.git/config <<-\EOF &&
	[abc]
	Qkey = one
	Qkey = two
	Qkey = three
	EOF
	q_to_tab >expect <<-\EOF &&
	[abc]
	Qkey = four
	Qkey = two
	Qkey = three
	EOF
	git config --replace-all abc.key four "o*" &&
	test_cmp expect .git/config
'

The end result is that _all_ existing values are removed in favor of one final result of abc.key=four.

Is this the intended behavior? It seems like value_regex is completely ignored instead of actually performing a function here. The only mailing list reference I can find include a doc update [2] and the original implementation from 2005 [3].

[2] https://lore.kernel.org/git/alpine.LFD.2.21.1805300733440.10096@localhost.localdomain/ [3] https://lore.kernel.org/git/Pine.LNX.4.63.0511200650130.12832@wbgn013.biozentrum.uni-wuerzburg.de/

If it is _not_ the intended behavior, then would a fix to make my test pass be appropriate? If anyone is currently specifying a value_regex to this command, then the behavior would change in surprising ways. However, it seems that they would get the same behavior without using value_regex.

Thanks, -Stolee

Derrick Stolee <stolee@gmail.com> writes:

I do not know or try to guess the original intention (I thought this is Dscho's thing, no?), but if there are one/two/three and I were asked to replace all of those that have zero or more 'o' in it with 'four' I would expect that

 (1) all three be removed, because they all have zero or more 'o',
     and then

 (2) one instance of 'four' be added,

resulting in a single 'four' left.

If the value_regex were "o+" (since it takes ERE) to mean one or more, then my expectation would be

 (1) one and two be removed, because 'three' does not match, and
     then

 (2) one instance of 'four' be added,

resulting in two items, 'three' and 'four'.

An alternative interpretation would be that each of the removed entries is replaced with a new one, resulting in three entries (i.e. with "o*", it would leave three identical entries 'four', with "o+", it would leave 'four', 'four' and 'three'), but that may be less useful in practice.

On 11/18/2020 1:54 PM, Junio C Hamano wrote:

Thank you. Naturally, PEBKAC and my lack of understanding the regex I was using in my own test. Clearly this is behaving correctly. Modifying as suggested shows this works properly.

Thanks, -Stolee

Derrick Stolee <stolee@gmail.com> writes:

It is an easy confusion.

When I see a pattern, especially a single letter followed by an asterisk like "o*", my eyes take it as a glob pattern that is left anchored, i.e. "any string that begins with an 'o'", and if that were the matching rule, what you expected is totally the natural outcome. But here we unfortunately are looking at ERE.