Junio C Hamano <junkio@cox.net> writes: > It _might_ work if you tell your downloader to have a proper > graft file in his repository to cauterize the commit ancestry > chain _before_ he pulls from you, though. I haven't tried it > (and honestly I did not feel that is something important to > support, so it might work by accident but that is not by > design). I just tried it and it actually works. $ git clone git.git junk $ cd junk ;# I am not brave enough to risk the real thing ;-) $ git rev-parse master~4 >.git/refs/info/grafts $ cd .. $ mkdir cloned $ cd cloned $ git init-db $ cp ../junk/.git/info/grafts .git/info/ $ git clone-pack ../baz $ git fsck-objects --full $ git log --pretty=short | cat This "only the tip of the git.git" repository has about 450 objects in it, fully packed because of clone-pack, with one 680K packfile. I think the true full history of git.git/ packed into one is aruond a 5MB packfile. I suspect a bigger repository would not see that much size reduction, as Linus already explained here. You could emulate what I just did above to prepare the equivalent of "baz" above, and make it available over git:// protocol, say at git://franck.example.com/franck.git/. Then you tell your downloaders something like this: This repository has been cauterized, and cannot be cloned in a usual manner, but once you make a clone everything including further incremental updates should work. To clone this repository: $ mkdir franckproject ;# make a new repository $ cd franckproject && git init-db $ echo 'XXxxxxXXxxx' >.git/info/grafts $ git clone-pack git://franck.example.com/franck.git/ - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Fri Jan 20 12:14:44 2006
This archive was generated by hypermail 2.1.8 : 2006-01-20 12:20:22 EST