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

From: Tanay Abhra <tanayabh@gmail.com>
Date: Oct 6, 2014, 18:59 UTC
Message-ID: <5432E67B.8070604@gmail.com>
In-Reply-To: <xmqqeguolxow.fsf@gitster.dls.corp.google.com>

On 10/4/2014 1:42 AM, Junio C Hamano wrote:

Show 49 quoted lines

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> 
>> Junio C Hamano <gitster@pobox.com> writes:
>>>> 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.

I have made some conclusions after reading the whole thread,

1> Add some tests for this use case which seems the most appropriate use case for this feature,

(Copied from Junio's mail)

    - Define "[xyzzy] frotz 1" in $HOME/.gitconfig (I think $HOME
      defaults to your trash directory).

    - Verify that "git config xyzzy.frotz" gives "1".

    - Define "[unset] variable = xyzzy.frotz" in .git/config (it is
      OK to use "git config unset.variable xyzzy.frotz" here).

    - Verify that "git config xyzzy.frotz" does not find anything.

    - Define "[xyzzy] frotz 2" in .git/config (again, it is OK to
      use "git config xyzzy.frotz 2" here).

    - Verify that "git config xyzzy.frotz" gives "2".

2> Leave the internal implementation as it is, as it helps in manually writing unset.variable in its appropriate place by using an editor, i.e this use case,

	[unset]
        	variable = ... nullify some /etc/gitconfig values ...
	[include]
        	path = ~/.gitcommon
	[unset]
		variable = ... nullify some ~/.gitcommon values ...
	[xyzzy]
		frotz = nitfol

3> Special case "unset.variable", so that git config unset.variable foo.baz pastes it on the top of the file. The implementation should be trivial, but, Junio had said in an earlier mail that he doesn't think this approach would do much good.

Other than this approach, Junio had suggested to append it after the last mention of "foo.baz", but I don't think if it would be worth it, but still I will cook up the code for it.

4> Change the name to config.unset or something.

I will make the above changes in the next revision.

Thanks.