Setting per-repository configuration for git

Hello everybody

I am looking into the git configuration mechanism and there seem to be a "hole" in use cases I'm trying to figure out...

git configurations can be saved at various places

* /etc/gitconfig : system-wide configuration
* ~/.gitconfig : user-wide configuration
* .git/config : repository-wide configuration

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...

Saving some configuration information within a repository is not unknown in git. .gitignore does it, and submodule configuration does it to.

I think it's important to have a way to have configuration options
be saved in a repository (and overridable with .git/config which 
is local-repository only) because a lot of configurationoptions
 are meant to express repository policies (triangular workflows,
merge vs rebase, mail vs push) and it would make sense to have
them transmitted that way.

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 ?

git (the project) shouldn't enforce policies on repositories, but I think it makes sense for repositories to have a way to set default policies on their clone...

Thx

Cordialement 

Jérémy Rosen +33 (0)1 42 68 28 04

fight key loggers : write some perl using vim 

Open Wide Ingenierie

23, rue Daviel 75012 Paris - France www.openwide.fr

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

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

Jeff King <peff <at> peff.net> writes:

Nb. *Mercurial* uses in repository .hgtags file for shared tags (instead of using separate transport mechanism, like Git does with refs, of which tags are special case). Said file has to be treated in a special way, with some sharp corner-cases (e.g. committing a tag (sic!)).