On Fri, Dec 11, 2020 at 03:47:38PM +0100, Patrick Steinhardt wrote: > The issue we have is that the config file isn't necessarily under our > control. It is in most cases, like e.g. when Gitaly gets deployed via > Omnibus. But we also allow for source-based installations, where the > user configures most things manually. And in that case, we have to ask > the user to "Please set config variables A, B and C". Naturally, this is > easy to forget, will drift apart in future releases and so on. For GitHub, we ship a VM appliance, so we just put what we want into /etc/gitconfig. I think in the worst case you could simplify everything down to "put [include]path=/usr/share/gitlab/gitconfig into your system config. Though I'm a little surprised that you wouldn't just ship your own version of Git that is used on the backend (so you know you have the right version, plus any custom patches you'd want), and then point its system config to /usr/share/gitlab/ or whatever. But I'm probably just showing my ignorance of your setup / install procedures, and there are a dozen reasons why that wouldn't work. ;) > To fix this, the plan is to move all required configuration items into > Gitaly itself, which GIT_CONFIG_COUNT would've allowd to do quite > nicely. Something like Ævar's proposal to allow reading the config from > a file descriptor would also work, and just putting the whole > configuration into an environment variable (similar to your > GIT_CONFIG_ENV_FILE, but containing contents instead of a path). And > finally, using `-c` would also work, with the downside of making it > harder to see what's going on with all the git processes. We do have a couple scripts (like our git-repack wrapper) that make heavy use of "git -c" to tweak things that don't have a command-line option, or for which using it is awkward. It does clutter up "ps" a bit, but it's sometimes nice to see the extra values, too (just as you'd see command-line options). -Peff
