Re: [PATCH/RFC 5/5] add tests for checking the behaviour of "unset.variable"

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 3, 2014, 20:12 UTC
Message-ID: <xmqqeguolxow.fsf@gitster.dls.corp.google.com>
In-Reply-To: <vpq4mvlgchj.fsf@anie.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 17 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> The "git config [--add] section.var value" UI, [...] finds the "var = value"
>> definition at the end (or adds a "section" at the end and then adds
>> [...]
>>
>> It is fine for single-valued ones that follow "the last one wins"
>> semantics; "git config" would add the new definition at the end and
>> that definition will win.
>
> Not always.
>
> git config foo.bar old-value
> git config unset.variable foo.bar
> git config foo.bar new-value
>
> One could expect the new value to be taken into account, but it is not.

I think you misunderstood what I said. With ordinary variables, everything works fine, that is, without unset.variable, which this series is trying to pretend as if it were just another ordinary variable, but it is not. You are just showing how broken it is to treat unset.variable as just another ordinary variable, which is what I've been telling you.

So we are in agreement.

Show 17 quoted lines

>>> Well, the normal use-case for unset.variable is to put it in a local
>>> config file, to unset a variable set in another, lower-priority file.
>>
>> I agree that is one major use case.
>>
>>> This common use-case works with the command-line "git config", and it
>>> would be a pity to forbid the common use-case because of a particular,
>>> unusual case.
>>
>> Either you are being incoherent or I am not reading you right.  If
>> you said "If this common use-case worked with the command-line 'git
>> config', it would be nice, but it would be a pity because it does
>> not", I would understand.
>
> I think you missed the "another" in my sentence above. The normal
> use-case is to have foo.bar and unset.variable=foo.bar in different
> files. In this case, you do not care about the position in file.

I didn't miss anything. The reason you want to have "unset foo.bar" in your .git/config is to override a "foo.bar = z" you have in another place, e.g. ~/.gitconfig; which would let you sanely do another "foo.bar = x" in .git/config for multi-value foo.bar, *if* the unset comes before foo.bar.

But what if you have this in your .git/config file

	[core]
		bare = false
            ... standard stuff left by git init ...
	[foo]
        	bar = x

before you add "unset foo.bar" there?

And that is not a contribed example.

The likely reason why you want to resort to "unset foo.bar" is that you found that you get an unwanted foo.bar=z in addition to desired foo.bar=z in a repository that has the above in .git/config, and at that point you would want to say "I want to unset the outside influence".

And there is no "[unset] variable = foo.bar" in there yet; without some special casing, if you treated unset.variable as if it were just another ordinary variable, it would go after you define your own foo.bar=x, which is not what you want.