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.
