gitaly: Stop writing a default gitconfig
What does this MR do?
The default gitconfig as written by CNG is quite misleading: Gitaly has been ignoring all of its current config entries it contains because it is injecting mandatory defaults on its own nowadays, and this has been true for a long time already. One ommission had been the Ruby sidecar, which still required the gitconfig to be around. But this has recently been fixed in Gitaly, where the sidecar now uses the same configuration as the main Go server.
Stop writing a default gitconfig to fix the confusion. Please note that
technically, Gitaly still does read the gitconfig. But it will only ever
use config entries whose values Gitaly doesn't overwrite itself. Admins
who require the ability to override keys set by Gitaly by default should
instead add [[git.config]]
entries to its config.toml
.
This also fixes an issue we have when different Git versions are in use.
While Git versions previous to v2.36.0 accepted core.fsyncObjectFiles
to enable the use of fsync(3P), this was changed to a new more flexible
core.fsync
config entry. So starting with Git v2.36.0, it would print
a warning whenever it sees the old Git configuration due to it being
deprecated. This means we need to conditionally inject gitconfig, which
is an easy thing to do in Gitaly itself. But it's hard to do with the
current model where we ship static gitconig files.
This change also prepares us for an upcoming change where Gitaly will
start to ignore any gitconfig files altogether, where the only way to
change Git configuration will then be the config.toml
.
Related issues
- Part of gitlab-org&8069 (closed).
- Blocked by gitlab-org/gitaly#4232 (closed).
- Blocked by gitlab-org/gitaly#4237 (closed).
- Blocked by gitlab-org/gitaly#4236 (closed).
- Fixes gitlab-org/charts/gitlab#3273 (closed).
Checklist
See Definition of done.
For anything in this list which will not be completed, please provide a reason in the MR discussion
Required
-
Merge Request Title, and Description are up to date, accurate, and descriptive -
MR targeting the appropriate branch -
MR has a green pipeline on GitLab.com
Expected (please provide an explanation if not completing)
-
Test plan indicating conditions for success has been posted and passes -
Documentation created/updated -
Integration tests added to GitLab QA -
The impact any change in container size has should be evaluated