From: Franck Date: Tue, 22 Nov 2005 09:22:46 GMT Subject: Re: [QUESTION] Access to a huge GIT repository. Message-ID: In-Reply-To: <7vhda5pw6l.fsf@assigned-by-dhcp.cox.net> 2005/11/21, Junio C Hamano : > Franck writes: > > > ... But since I used grafting to "cut" > > my light repo and .git/info/grafts file is not copied during > > push/pull/clone operations it's not going to work. Is it a scheme that > > could work ? > > If you tell your downloaders that your repository is incomplete > and they need to have at least up to such and such commits from > another repository, they should be able to slurp from you. > What do you mean by "have at least up to such and such commits" ? I can see only one commit that they need: the one I used to create my public repository... > It might be possible to teach upload-pack (that is run when your > downloaders run git-fetch or git-clone against your repository) > to somehow send a customized error message to the client when it > finds the other end needs certain objects that you yourself do > not even have. In that message you could say something like "due > to space constraints this repository is an incomplete one, and > you can only use it on top of a clone of such and such > repository, found at this URL: ...". > That's a good idea. We get the same thing when cloning linux repository. BTW how is it done in that case ? > > Moreover, I'm wondering if my public repository really needs to store > > big repo's pack files as it is described in git tutorial ? > > What you are trying to do is to keep your public repository > fsck-objects *un*clean and still let downloaders work with it; > so I suspect following that section of the tutorial procedure > defeats the purpose your experiments. > Absolutely. My question was not accurate sorry. It should have been "can I have a public repository wiith fsck-objects unclean and with a grafts file that should be downloaded when cloning it. Thanks -- Franck