Description
Background
In history, Gitea uses default (system/global) git config file. It would cause a problem: conflicting with user's git config if the Gitea instance is running without isolation. Related:
- git config option color.diff can break diff and commit graph #3220
- gitconfig: set safe.directory = * #19870
Proposal
According to: https://git-scm.com/docs/git-config#_environment , set GIT_CONFIG_GLOBAL to use a git config inside Gitea's data directory, and set GIT_CONFIG_NOSYSTEM to skip the system git config.
Update: at the moment, GIT_CONFIG_GLOBAL is not used because it's only supported by new Git. To make Gitea work with some old Git, the internal git HOME environment is used. And GIT_CONFIG_NOSYSTEM is still supported, in case some users need to put some config options in it.
Benefits
Then Gitea can set any git option it needs in its own customized git config. And it avoids unexpected git problems caused by user's incorrect git config.
Breaking or not
To upgrade from an existing Gitea instance (there is no customized git config for Gitea yet):
-
Breaking way: if there is no customized git config for Gitea, then ignore the existing git config and create a new customized git config for Gitea from scratch. If some users ever set some options for Gitea in their global/system git config, this way would lose these options. Users can set these options in the customized git config manually later.
-
Non-breaking way: copy the existing global/system git config options into the customized git config. This way would bring in some unrelated (maybe incorrect) config options.
In my mind the Breaking way is the preferred method, because it's clear, and normally users shouldn't have set any Gitea-related options in their git config. So it's not that breaking indeed.