Re: [QUESTION] Access to a huge GIT repository.

From: Junio C Hamano <junkio@cox.net>
Date: Nov 21, 2005, 20:45 UTC
Message-ID: <7vhda5pw6l.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <cda58cb80511211211l2ff6ff12j@mail.gmail.com>

Franck <vagabon.xyz@gmail.com> 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.

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: ...".

> Moreover, I'm wondering if my public repository really needs to store
> big repo's pack files as it is described in git tutorial ?

Copying is one way, but if the repository you are borrowing from lives on the same machine, you could use objects/info/alternates to point at it from your public repository. In either case, the point in that section is to reduce the need to transfer and expand much stuff in your public repository while keeping the repository complete. The recommended procedure in the tutorial always assumes that the public repository is kept fsck-objects clean and complete.

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.