Re: [PATCH/RFC 0/5] add "unset.variable" for unsetting previously set variables

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 2, 2014, 19:58 UTC
Message-ID: <xmqqvbo2meg5.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1412256292-4286-1-git-send-email-tanayabh@gmail.com>

Tanay Abhra <tanayabh@gmail.com> writes:

> 2> It affects both the C git_config() calls and, git config shell
> invocations. Due to this some variables may be absent from the git config -l
> result which might confuse the user.

I am not sure what you mean by this. If you process variable definitions as they come, and you read

	[some]
		variable = set to some value initially
                ...
	[unset]
		variable = some.variable
		...
	[some]
		variable = set to some other value

then a user might be able to see

	$ git config -l
        some.variable=set to some value initially
        !some.variable
	some.variable=set to some other value

(here, I am using an imaginary "!variable.name" to denote "this variable is unset at this point in the reading sequence").

I would imagine if the result comes from a caching layer, the user would see

	$ git config -l
	some.variable=set to some other value

and nothing else.  Is that what you are referring to?

I would think that the latter is probably desirable; otherwise we would need to come up with a way to say "forget about everything we said about this variable so far" (i.e. my "!some.variable" above) and also the scripts that parse "git config -l" output need to code the logic to forget and start afresh.

> 3> I also have an another implementation for this series which just marks the config
> variables instead of deleting them from the configset. This can be used to
> provide two versions of git_config(), one with filtered variables other without
> it.

I do not see a value in the filtered version.

What worries me _more_ is why people may want to put things in system-wide global, and if it is a wise thing to do to allow users to override.

We may later want to add ways to mark variables in various ways, e.g. (thinking aloud)

 - "[config] sealed = section.variable" will prevent the variable
   from being reset, modified or appended.  If an administrator
   wants to enforce a certain setting in /etc/gitconfig, she may
   mark sensitive variables as cofnig.sealed at the end of the file:

	[security]
        	enforced = true
                ...
	[config]
        	sealed = security.enforced

   and we would ignore

	[config]
        	unset = security.enforce
        [security]
		enforce = false

   written in .git/config or ~/.gitconfig, perhaps?

 - "[config] safeInclude = path" will allow a configuration file to
   be included safely from the project's working tree.  The path
   given as the value must be a relative path and it is relative to
   the top level of the project's working tree.

 - "[config] safe = section.variable" will list variables that can
   be included with the config.safeInclude mechanism.  Any variable
   that is not marked as config.safe that appears in the file
   included by the config.safeInclude mechanism will be ignored.

   The 'frotz' project might have a .frotz-gitconfig file at the
   root level of its working tree that stores this:

	[diff]
        	renames = true

   and your .git/config may have

	[config]
        	safe = diff.renames
                safeInclude = .frotz-gitconfig

   You will not have to worry about a malicious participant
   committing a

	[diff]
        	external = rm -fr .

   to .frotz-gitconfig and pushing it to the project because you do
   not mark diff.external as config.safe in your .git/config