Re: restriction of pulls

[Andy Parkins <andyparkins@gmail.com>]

On Friday 2007 February 09 15:32, Rogan Dawes wrote:

> One obstacle to implementing partial checkouts is that one does not know
> which objects have changed or been deleted. One way of addressing this

Why would you want to do a partial checkout.  I used subversion for a long 
time before git, which does to partial checkouts and it's a nightmare.

Things like this

 cd dir1/
 edit files
 cd ../dir2
 edit files
 svn commit
 * committed revision 100

KABLAM!  Disaster.  Revision 100 no longer compiles/runs.  The changes in dir1 
and dir2 were complimentary changes (say like renaming a function and then 
the places that call that function).

I didn't even notice how awful it was until I started using git and had a VCS 
that did the right thing.

In every way that matters you can do a partial checkout - I can pull any 
version of any file out of the repository.  However, it should certainly not 
be the case that git records that fact.

I think what you're actually after (from your description) is a shallow clone.  
I believe that went in a while ago from Dscho.

 $ git clone --depth=5 <someurl>

Will fetch only the last 5 revisions from the remote.  The other half to that 
is a shallow-by-tree clone; that is anathema to git as there is no such thing 
as a partial tree.  Submodule support is what you want, but that's still in 
development.

The only piece that (I think) is missing to get the functionality you want is 
a kind of lazy transfer mode.  For something like, say, the kde repository 
you can do

 svn checkout svn://svn.kde.org/kde/some/deep/path/in/the/project

And just get that directory - i.e. you don't have to pay the cost of 
downloading the whole of KDE.  Git can't do that; however, I think one day it 
will be able to by choosing not to download every object from the remote.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com