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

Junio C Hamano [off-list ref] writes:

Tanay Abhra [off-list ref] writes:

quoted

I can think of two solutions, one leave it as it is and advertise it to be
explicitly typed in the config files at the appropriate position or to change
the behavior of unset.variable to unset all matching variables in that file,
before and after. We could also change git config --add to append at the end
of the file regardless the variable exists or not. Which course of action
do you think would be best?

Off the top of my head, from an end-user's point of view, something
like this would give a behaviour that is at least understandable:

 (1) forbid "git config" command line from touching "unset.var", as
     there is no way for a user to control where a new unset.var
     goes.  And

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.

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.

 (2) When adding or appending section.var (it may also apply to
     removing one--you need to think about it deeper), ignore
     everything that comes before the last appearance of "unset.var"
     that unsets the "section.var" variable.

That would probably be the best option from a user's point of view, but
I'd say the implementation complexity is not worth the trouble.

Alternatively, if the syntax to unset a "section.var" were not

	[unset]
        	variable = section.var

but rather

	[section]
		! variable

or soemthing, then the current "find the section and append at the
end" code may work as-is.

But that would break backward compatibility rather badly: old git's
would stop working completely in repositories using this syntax.

Well, perhaps we can also consider that this is acceptable: just don't
use the feature for a few years if you care about backward
compatibility.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/