Skip to content
Snippets Groups Projects
Commit 2894e127b281 authored by Patrick Steinhardt's avatar Patrick Steinhardt
Browse files

Drop default values for `omnibus-gitconfig`

The `Gitlab['omnibus-gitconfig']['system']` attribute used to contain
Git configuration that was subsequently used by Gitaly. This was done by
writing its config entries into the global `gitconfig` file so that they
were picked up by all Git commands.

This has proven to be insufficient in the context of Gitaly, which needs
a lot more fine-grained control over the exact Git configuration it uses
when spawning Git commands. One point in case was the deprecation of the
old `core.fsyncObjetFiles` configuration, which if present caused us to
print user-visible warnings.

We have since moved all default Git configuration into Gitaly itself,
which thus does not need any external Git configuration by default
anymore. Furthermore, we have implemented a mechanism in Gitaly to just
plain ignore the global `gitconfig` file -- instead, non-default Git
configuration needs to be written into Gitaly's `config.toml`.

In Omnibus though we still carry legacy defaults that were used for the
Git configuration back when Gitaly didn't yet knew to set up its own
defaults. As we know to strip those defaults when writing Gitaly's
`config.toml` they don't apply at all in that context, but we still
write them into the global `gitconfig` file. Consequentially, these
defaults apply to all Git commands not spawned by Gitaly itself.
Arguably though this is not required:

    - `pack.threads=1` controls how many packs should be used when
      writing Git packfiles. This was added to limit the amount of
      resources a single Git process could use in the context of Gitaly.

    - `receive.fsckObjects=true` asks Git to perform consistency checks
      for objects when serving a push. We should never accept pushes
      into Git repositories outside of Gitaly anyway.

    - `receive.advertisePushOptions=true` asks Git to advertise the
      availability of push options to clients when serving a push.
      Again, we should never accept pushes into Git repositories outside
      of Gitaly.

    - `transfer.hideRefs` hides various internal namespaces when serving
      fetches and pushes. Same as above, we should not accept pushes
      into Git repositories outside of Gitaly.

    - `repack.writeBitmaps=true` asks Git to write bitmaps via
      git-repack(1). This would even be wrong if git-repack(1) was to be
      executed in a repository that is connected to an object pool.

    - `fetch.writeCommitGraph=true` asks Git to write commit-graphs when
      fetching into a repository. This data structure is used to speed
      up various operations. There is no reason to enable this globally.

    - `core.alternateRefsCommand="exit 0 #"` will disable listing
      alternate references when a repository is connected to another
      repository. There is no reason to disable this globally.

    - `core.fsyncObjectFiles=true` is the only one that is debatable as
      it enables calling fsync(3P) when writing objects into a Git
      repository. This option has been deprecated in Git v2.36.0 though
      and causes deprecation warnings to be printed on every invocation
      of Git. So if at all, we would want to set `core.fsync` nowadays
      to enable this code again. On the other hand though there should
      be no manual commands that write Git objects into repositories
      controlled by Gitaly in the first place as that is not supported.

Drop all the default values. All of these config entries are managed by
Gitaly already, have no obvious purpose when running Git commands
globally and add complexity and confusion around what the actual
configuration is now.

Changelog: removed
parent de01e768b91a
2 merge requests!102heptapod#1237: making 0.38 the new oldstable,!89Merged upstream 15.8.0+ce.0
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment