Re: .gitlink for Summer of Code

Eric Lesh [off-list ref] 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.

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.

-- 
Matthieu

Matthieu Moy [off-list ref] wrote:

Eric Lesh [off-list ref] writes:

quoted

.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...  ;-)
 

quoted

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.

Hi,

On Sun, 25 Mar 2007, Shawn O. Pearce wrote:

Matthieu Moy [off-list ref] wrote:

quoted

Eric Lesh [off-list ref] writes:

quoted

.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.

Not only that. You'd have to change the way read_sha1_file() is called to 
allow fetching more than one object at a time. Otherwise this will be so 
slow as to be unusable.

That's basically the reason why I changed my mind, and preferred shallow 
clones over lazy clones.

Ciao,
Dscho

Johannes Schindelin [off-list ref] wrote:

On Sun, 25 Mar 2007, Shawn O. Pearce wrote:

quoted

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.

Not only that. You'd have to change the way read_sha1_file() is called to 
allow fetching more than one object at a time. Otherwise this will be so 
slow as to be unusable.

Yes, and no. ;-)

Lets say we put a repository on an NFS share, and clone it using
--shared.  So it's now an alternate ODB.  And read_sha1_file()
is now doing synchronous reads, unless the client has something
cached.  Which we could just as easily cache ourselves in the
loose object directory

We could make it faster by batching up requests.  But batching
requests may be difficult in some contexts, as we don't know what
else we need until we get back that commit or tree we are trying
to read.  ;-)
 
-- 
Shawn.

On Sun, 2007-03-25 at 17:20 +0200, Matthieu Moy wrote:

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.

For now, this is really meant for quick and easy access to multiple
branches of your own repo at the same time.

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.

There is no .git dir for these.  The .gitlink refers back to the main
repository's .git/external/$submodule, which is a full .git dir with
index+HEAD and symlinks back to the .git of the main repo for everything
else.

-Eric

Matthieu Moy wrote:

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.

It would be special-cased, as is .git directory not versioned, the
same way .gitlink would be not versioned (not like .gitignore).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git