From: Junio C Hamano <junkio@cox.net>
Date: Mon, 21 Nov 2005 19:29:44 GMT
Subject: Re: [RFC 1/2] Use remote information in .git/config
Message-ID: <7v4q65sst3.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0511211452470.13775@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> This patch allows to store shortcuts for fetch/pull into the config:
>
> 	[remote.junio]
> 		url = http://www.kernel.org/pub/scm/git/git.git
> 		pull = master:junio
> 		pull = todo:todo
> 		pull = +pu:pu
>
> Note that there is only one pair per "pull" line, to allow for spaces
> (urgh!) in the branch names.

I think "allow for spaces" nonsense can be removed by now.  I
did it initially that way before making the ref name validation
tighter with check-ref-format.  And if I understand what you
wrote about multivalues correctly, your intent is that "orders
do not matter"; with pull refspecs, orders do matter, so it
probably is a good idea to allow only a single line.

Personally I do not mind moving remotes/branches information
there, except that I suspect the git-config-set interface makes
it cumbersome to (1) find out what remotes I defined (i.e. an
equivalent of "ls .git/remotes") and (2) remove a single remote
when I do not want it anymore (--unset-all would remove the keys
but would leave the empty section).

I am unsure if putting everything in .git/config file is the
right approach, though.  What will we put there next?  ls-files
ignore patterns?  grafts?  alternates?  We should be able to
even get rid of .git/refs directory hierarchy and replace that
with something like this:

	[refs]
        	head = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234	for master
        	head = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234	for pu
		tag = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234 for v1.0rc1
	...

Where will we stop, and why?

I am worried about people later asking "why do we have X in
config but not Y"?