Web lists-archives.com

Re: [PATCH (Apple Git) 12/13] Enable support for Xcode.app-bundled gitconfig




Jeremy Huddleston Sequoia <jeremyhu@xxxxxxxxx> writes:

>>>> A concern shared with 13/13 is this.
>>>> 
>>>> While it may not hurt too much to look at one extra location even on
>>>> non-Apple platform, it probably is a mistake to have this xcode
>>>> specific change in generic part of the system like config.c or
>>>> attr.c.  For that matter, would it make sense to force Apple uses to
>>>> look at one extra location in the first place?  In other words, we
>>>> already have "system wide" location (i.e. system_path(ETC_GITCONFIG))
>>>> defined so system owners can give reasonable default to its users.
>>>> The value of not using that facility and instead adding yet another
>>>> place is dubious.
>>> 
>>> This allows for per-distribution configuration and could be useful for
>>> other applications as well that want customizations specific to their
>>> install of git.  For our specific use case, we do not want to munge the
>>> system policy when installing Xcode.  Prior to doing things this way, we
>>> were just changing the default in our distributed git binary, but this
>>> seems a bit more flexible.
>> 
>> I think you misunderstood Junio, thinking that he referred to
>> /etc/gitconfig. He did not. system_path(ETC_GITCONFIG) refers to
>> <prefix>/etc/gitconfig, where <prefix> is that runtime prefix when
>> compiled with RUNTIME_PREFIX.
>
> Oh!  Awesome.

I do not think you misunderstood.  system_path(ETC_GITCONFIG) may be
in <prefix>/etc/gitconfig when building with RUNTIME_PREFIX, but
then I do not think /etc/gitconfig (without <prefix>) comes into the
picture.  So as long as you want to add "a forced by distribution,
not editable by end user to set a global policy for the entire box"
configuration, that goes against the design of the configuration
system, which wants to have three levels (i.e. per repository, per
user and per box).

I think the arrangement jrnieder illustrates in a message in this
thread to use the inclusion of distro-provided file from
/etc/gitconfig, which documents what is happening clearly and still
allows the user to disable the distro-provided one if needed, is
probably the best solution under the current design.