Where does the local /.git/config come from? i.e. on a fresh git clone, .git/config has some content. How is it configured/altered so that the next git clone will have them?

By experiment, you can't make modifications to .git/config and push them.

They are surely stored someplace on the repo, but github doesn't seem to show a .git directory.

thanks in advance

CodePudding user response：

Where does the local /.git/config come from? i.e. on a fresh git clone, .git/config has some content. How is it configured/altered so that the next git clone will have them?

It's not. This file is local to your repository and is created by the git command when initializing your local directory. There would be substantial security implications if this file came from the remote repository (because it would allow someone to run arbitrary code on your system).

If you want to have consistent settings for multiple developers, the solution is to distribute some sort of script or instructions that can be used to correctly configure the repository. For example, a lot of people use the pre-commit command to help configure pre-commit hooks.

CodePudding user response：

On a server hosting repositories, you typically have only bare repositories. In that case, the local configuration is stored as the file config within the bare repository, because a bare repository is essentially one where you have only the .git directory and no working tree.

However, configuration is not passed over a clone or fetch. Git intentionally doesn't have any way to do this because in general anyone who can modify the configuration can cause arbitrary code to be executed on the system, which obviously is a security problem. The initial configuration when you set up a new repository is done by Git detecting what's on the system, such as whether file modes and symlinks are supported.

If you need to set some configuration, then you can do so with a script. Having said that, you should not configure things like core.filemode, core.symlinks, or other autodetected options that way because it will break Git. If core.symlinks is set to false, then your file system doesn't really support symlinks, and setting it to true won't change that. You need to instead ask Windows developers to enable Developer Mode so that Git will autodetect the right setting. You may choose to make your setup script fail in such a case and have the user fix the situation and re-clone the repository or re-run git init (possibly followed by git checkout -f).