Re: .gitlink for Summer of Code

["Shawn O. Pearce" <spearce@spearce.org>]

Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Eric Lesh <eclesh@ucla.edu> 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.