Git upgrade to v2.36.1 results in warning due to `core.fsyncObjectFiles` set in distributions
With Git v2.36.0, the Git project has introduced a new core.fsync
file that has replaced the old core.fsyncObjectFiles
configuration. In the process, Git has introduced a new warning that gets printed when the old value is still set so that it can slowly be phased out. Unfortunately, this warning is something that bothers us because it is printed on every Git command invocation, including executables like git-receive-pack(1) and git-upload-pack(1). Consequentially, a user who would fetch from or push to a remote repository would get this warning printed to his command line. This is very much confusing for the user, and we don't want that because it boils down to a bad user experience.
In Gitaly, we have thus taken precautions to not inject the old core.fsyncObjectFiles
configuration anymore in case we're running with a Git version equal to or newer than v2.36.0, and instead inject core.fsync
now. One part that has not been adjusted though is both CNG and Omnibus, which still have the old configuration present in their gitconfig. Which means that the warning will still be printed, because it still exists.
Now theoretically, we could just remove that configuration from both distributions and be done. But unfortunately, we require the configuration to be present so that libgit2 can pick it up: it must be configured to flush object files to disk, or otherwise we may experience corrupted repositories in certain edge cases. But if that configuration contains the core.fsync
setting then libgit2 wouldn't recognize it, whereas if it contains the core.fsyncObjectFiles
configuration then Git would print a warning.
So it clear that we cannot use the global Git configuration to set this up correctly. Instead, it should be fixed both in gitaly-git2go
and the Ruby sidecar by manually forcing this configuration to true
so that libgit2 is always flushing object files to disk. But unfortunately, neither Git2go nor Ruby expose the necessary wrappers that would allow us to tweak the Git configuration without also writing the gitconfig to disk. Which means that we have no other choice than to rely on a gitconfig to exist.
We could in theory work around this issue: both wrappers support modifying the search path for the gitconfig file. So if we wrote a temporary gitconfig that contains the necessary keys, and then configure libgit2 to use it, then the issue would essentially be solved. But right now, we're still supporting setups where the gitconfig is set up by the administrator, and clobbering that value means that we have broken previously supported setups.
Luckily, we did in fact announce the deprecation of the gitconfig for %15.0, but we have originally deferred it two weeks ago to %16.0 because of the required changes that are in fact documented in this very issue here. But given that this is now blocking Git version upgrades we may want to reconsider.