Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Josef Weidendorfer <Josef.Weidendorfer@gmx.de>]

On Monday 28 November 2005 09:43, Andreas Ericsson wrote:
> Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > 
> >>I only realized that we -- in the good tradition of UNIX -- have many 
> >>different formats for different configurations: Some configurations are in 
> >>.gitignore, some are in .git/branches/, some in .git/remotes/, some in 
> >>.git/config, and even some in environment variables!
> > 
> > 
> > Can you live with something like this?
> > 
> >  - we will add new ones to config, now we have it;

It is not really fitting for all purposes (eg. syntax restrictions).


> I'd still like to see git-repo-config and git-user-config. Otherwise 
> we'll need to continue having user-based environment variables 
> (GIT_COMMITTER_IDENT and friends).

In fact, it would be nice to have different "config levels" supported
by git. I can imagine:
(1) user config (typically in $HOME/.gitrc)
(2) project config (in .git/project.conf)
(3) repository config; i.e. separate for every clone
    (in .git/repo.conf instead of .git/config as of now?)
Even for one such level, it would be nice to be able to seperate the
config into multiple files; ie. remote config in a .git/remote.conf,
and a porcelain should be able to have its own config files, but still
using git's config parser.

To allow for this, git_config() should not be hardcoded to only
read .git/config, but perhaps a list of files in environment variable
GIT_CONFIG_FILES.

For (2), git-clone should copy some files, e.g. the .git/project.conf
or .git/info/exclude. But project config probably should be kept
up to date among all repositories for a project, i.e. it should be
version controlled itself, but independent from the project.
We could use a project config head .git/refs/projectconfig for this;
of course post-1.0 material.


Josef