Re: Setting per-repository configuration for git

From: Jeff King <peff@peff.net>
Date: Oct 25, 2013, 08:25 UTC
Message-ID: <20131025082513.GE17029@sigill.intra.peff.net>
In-Reply-To: <834511791.9670586.1382685155770.JavaMail.root@openwide.fr>

On Fri, Oct 25, 2013 at 09:12:35AM +0200, Jeremy Rosen wrote:

Show 7 quoted lines

> however I can't find a way to have the repository's configuration 
> saved and transmited with the repository in a way similar to how
> .gitignore is transmitted...
> [...]
> Knowing how mature git is I can only assume that this has already
> been discussed and that there is a good reason not to do it. Is it
> because of hooks ? would it break something I don't see in git ?

There are a few reasons.

One, there are security implications. You can execute arbitrary code using git config options (e.g., by defining diff helpers). While it's true that you often run the code that you fetch into your git repository, you at least have an opportunity to verify it using git commands before it is run.

Two, the config is not really tied to a specific revision in the same way that a .gitignore is. If I move to another branch, or checkout an old revision, I would want to use the .gitignore from the currently checked-out commit. But git config does not typically work that way. If I am sight-seeing back to last year's history, I do not want to use a different remote URL, or different diff settings, etc. So managing a .gitconfig directly in the repository has some ugly edge cases.

I have proposed in the past letting config includes access git objects directly. Then a project could ship dedicated config in the "config" branch, and you would always use the tip of that branch, even if you were moving your working tree elsewhere in history. And if you want to protect yourself from incoming config, you can point it to your _local_ config branch, and only merge remote changes to it after verifying they are sane.

That would address both issues, but after some discussion, we realized that you are really not any better off than simply pulling the data out of git and including it as a file. So something like:

  1. Project ships recommended git config settings as `docs/gitconfig`.

  2. User clones the repo.

  3. User looks at `docs/gitconfig`, verifies that it's OK.

  4. User copies `docs/gitconfig` to `.git/project-config`.

  5. User points git at project config with `git config include.path
     project-config`.

  6. Periodically, user examines updates to `docs/gitconfig` and copies
     it to `.git/project-config`.

I don't know of any projects that do this, though, or even that ship a recommended config. I don't know what one would put in such a config file. Most settings are matters of personal preference, or local configuration for the machine.

-Peff