From: Junio C Hamano Date: Thu, 31 Jan 2019 18:06:12 GMT Subject: Re: [PATCH (Apple Git) 12/13] Enable support for Xcode.app-bundled gitconfig Message-ID: In-Reply-To: Jeremy Huddleston Sequoia 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 >> /etc/gitconfig, where is that runtime prefix when >> compiled with RUNTIME_PREFIX. > > Oh! Awesome. I do not think you misunderstood. system_path(ETC_GITCONFIG) may be in /etc/gitconfig when building with RUNTIME_PREFIX, but then I do not think /etc/gitconfig (without ) 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.