Re: restriction of pulls

From: Rogan Dawes <lists@dawes.za.net>
Date: Feb 9, 2007, 15:32 UTC
Message-ID: <45CC941E.9030808@dawes.za.net>
In-Reply-To: <Pine.LNX.4.63.0702091554160.22628@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin wrote:

Show 13 quoted lines

> Hi,
> 
> On Fri, 9 Feb 2007, Christoph Duelli wrote:
> 
>> Is it possible to restrict a chechout, clone or a later pull to some 
>> subdirectory of a repository?
> 
> No. In git, a revision really is a revision, and not a group of file 
> revisions.
> 
> Ciao,
> Dscho
>

I thought about how this might be implemented, although I'm not entirely sure how efficient this will be.

One obstacle to implementing partial checkouts is that one does not know which objects have changed or been deleted. One way of addressing this is to keep a record of the hashes of all the objects that were NOT checked out. (If one does not check out part of a directory, simply store the hash of the top level, and you do not need to store the child hashes.) This record would be a kind of "negative index".

When deciding what to check in, or which files are modified, one would check the "negative index" first to see if an entry exists. If not, only then would you check the filesystem to see if modification times have changed. With the "negative index", and the files in the file system, one would be able to construct new commits, without any problem.

It would also require an updated transfer protocol, which would allow the client to specify a tag/commit, then walk the tree that it points to to find the portion that the client is looking for, then pull only those objects (and possibly their history). This is likely to be VERY inefficient in terms of round trips, at least initially.

This might be able to benefit from the shallow checkout support that was recently implemented.

Comments?

Rogan