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

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Nov 28, 2005, 15:03 UTC
Message-ID: <200511281603.54433.Josef.Weidendorfer@gmx.de>
In-Reply-To: <20051128134808.GQ22159@pasky.or.cz>

On Monday 28 November 2005 14:48, Petr Baudis wrote:

Show 7 quoted lines

> Dear diary, on Mon, Nov 28, 2005 at 01:59:04PM CET, I got a letter
> where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> > (2) project config (in .git/project.conf)
> 
> What are you going to keep in it? There isn't much of stuff which is not
> per-user or per-instance. I can't think of anything now, but there is no
> list of configuration variables to check yet.

Project global configurations could be:
- .git/info
- .git/hooks
- default for encoding of commit messages
- relationship of public project branches (perhaps access rights)
- project description, maintainers, public branch descriptions
- central repository URL
- ...

> (Upstream maintainer email is interesting, OTOH it alone doesn't seem to
> justify the mechanism by itself; also, the upstreams may be different
> based on where you cloned the project from, etc.)

Hmm.. this even could be seen as another level: origin specific

Show 10 quoted lines

> > 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.
> 
> If you still want per-project config, why should it be independent from
> the project? Actually, like you have .gitignore, having something like
> .gitconfig

That doesn't work well with configuration which should be global to the whole history of the original project, e.g. .git/info/exclude, or maintainer information.

> in project root would be by far the simplest - if you want 
> separate head, your merging and stuff gets quite more complicated, as
> well as actually branching the project config, etc.

Project configuration probably always should be up to date, so:
* always update when fetching/pulling project branches
* always push when pushing project branches

Josef