> On Jan 30, 2019, at 16:01, Jonathan Nieder <jrnie...@gmail.com> wrote:
>
> Hi,
>
> Jeremy Huddleston Sequoia wrote:
>
>> Unfortunately, I was quick to celebrate. This picks up the bundled
>> file instead of a system-wide file. I'd love it if we could still
>> honor system-wide config/attributes in addition to
>> RUNTIME_PREFIX-relative ones (eg: user overrides system which
>> overrides distribution). I worry that as is, we'd stop referencing
>> the system-wide configs which might confuse users.
>>
>> Is that something you'd be interested in, or should we just continue
>> to maintain our separate patches?
>
> For the internal deployment at Google, what we've done is to put an
> [include] path directive in the global gitconfig:
>
> [include]
> path = /usr/share/git-core/config
>
> Users can edit the global git config in etc, but the distributed
> config at /usr/share/git-core/config is read-only as part of the
> distributed package.
>
> We considered making an upstream change to bake in the distributed
> config in the git binary but decided that this way is a little
> nicer since it lets people comment out the include.path setting if
> they want to e.g. for experimentation. It's also more explicit
> (hence easier to understand).
>
> Would a similar approach work for your setup? Can you say a little
> more about how you'd like things to work from an end-user pov?
That might work. I could put this in the Xcode.app gitconfig:
[include]
path = /private/etc/gitconfig
Would that result in /private/etc/gitconfig's taking precedence or Xcode.app's?
Is there anything analogous I could do for gitattributes?
