From: Shawn O. Pearce Date: Sun, 25 Mar 2007 20:39:01 GMT Subject: Re: .gitlink for Summer of Code Message-ID: <20070325203901.GB12376@spearce.org> In-Reply-To: Matthieu Moy wrote: > Eric Lesh writes: > > > .gitlink is for a lightweight checkout of a branch into a separate > > directory on the local filesystem. > > I think it's a pitty to restrict yourself to _local_ filesystem. There > are tons of cases where you have a fast, non-NFS, access to a machine > and would like to host your repository there. > > That said, I suppose removing this restriction moves the solution from > the category "quick and efficient hack" to something much harder. Yes. But there's another project on the ideas list that addresses that (``Lazy Clone''). It is quite a bit more difficult than the .gitlink idea as the implementation requires a network protocol client implemented somewhere near the read_sha1_file interface. Junio and I had talked about this (I think it was on the list, but maybe it was on #git) recently and considered maybe trying to do it as a wrapper *above* read_sha1_file/has_sha1_file, and adjust the clients that call them to invoke the wrapper instead. Nothing will obviously beat having the file on a local disk; but if you have a fast LAN it may be hard to beat an anonymous TCP socket dedicated to serving Git objects. Such a socket may even beat out NFS... ;-) > > A .gitlink'ed checkout has its own index+HEAD, but otherwise refers > > back to the main repository for objects, refs, etc. > > Stupid question: why .gitlink, and not .git/link or so? This file is > not versionned, I don't think it should be in the working tree. I've thought the same thing. Actually, I'd almost say put it into .git/config, e.g.: mkdir .git cat >.git/config <