Setting per-repository configuration for git

Setting per-repository configuration for git

[Jeremy Rosen]

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

Re: Setting per-repository configuration for git

[Jeff King]

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

> 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

Re: Setting per-repository configuration for git

[Jakub Narebski]

Jeff King <peff <at> peff.net> writes:
> On Fri, Oct 25, 2013 at 09:12:35AM +0200, Jeremy Rosen wrote:
> 
> > 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...
> > [...]

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

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

-- 
Jakub Narębski