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

[Franck <vagabon.xyz@gmail.com>]

2005/11/21, Junio C Hamano <junkio@cox.net>:
> 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.
>

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