From: Johannes Schindelin Date: Mon, 21 Nov 2005 20:24:44 GMT Subject: Re: [RFC 1/2] Use remote information in .git/config Message-ID: In-Reply-To: <7v4q65sst3.fsf@assigned-by-dhcp.cox.net> Hi, On Mon, 21 Nov 2005, Junio C Hamano wrote: > Johannes Schindelin writes: > > > 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. Okay. (I also wondered how git-config-set could be used to replace the first pair, which is what gets merged when pulling). > 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). (1) git-var -l | grep '^remote\.' (2) I would add --remove-section for that. (Though I'll wait to implement that until I know if people want it.) > 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? Ahh! I have a clear picture of what *I* would put into it: all interesting static data about that particular repository which I would not like to version. For that matter, .gitignore would stay where it is, though I'd also like to version grafts, i.e. move the location from .git/info/grafts to .gitgrafts (which would effectively end another thread on this list). I would not like to version refs, evidently, or alternates. But the refs would not be static (they *want* to change often), while the alterates would be. But I will not be a bugger about it. If things stay where they are (including .git/remotes), I will not be sad. There was just this crazy idea in my head (not the tip of the development branch, but the object my eyes are in), and I wanted to discuss it with you guys, just in case... Ciao, Dscho