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@xxxxxxxxx - 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