Matthieu Moy <Matthieu.Moy@xxxxxxx> wrote: > Eric Lesh <eclesh@xxxxxxxx> 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 <<EOF [core] repositoryversion = 0 filemode = true link = /path/to/source EOF as then the index and HEAD file can both be stored in .git, just like with the non-gitlink case. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html