Tanay Abhra <tanayabh@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html