> On Jan 30, 2019, at 16:01, Jonathan Nieder <jrnieder@xxxxxxxxx> 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?
