You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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:
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 setGIT_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 gitHOME
environment is used. AndGIT_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 thatbreaking
indeed.Reference
The text was updated successfully, but these errors were encountered: