Re: Clone fails on a repo with too many heads/tags

[Jeff King <peff@peff.net>]

On Sun, Mar 18, 2012 at 09:36:24AM -0700, Jakub Narebski wrote:

> > The solution is conceptually simple: if the list of refs results in a too long 
> > command line, split the refs in batches and call fetch-pack multiple times such 
> > that each call is under the cmdline limit:
> > 
> > git fetch-pack --stateless-rpc --lock-pack ...<first batch of refs>...
> > git fetch-pack --stateless-rpc --lock-pack ...<second batch of refs>...
> > ...
> > git fetch-pack --stateless-rpc --lock-pack ...<last batch of refs>...
> 
> That, or implement --stdin / --revs in git-fetch-pach (perhaps
> following git-pack-objects that implements --revs).

I don't think that will work, as stateless-rpc fetch-pack already uses
stdin to receive the list of advertised refs from the remote. Nor would
you want to have multiple invocations of fetch-pack, since that would
mean multiple http requests and multiple pack responses (which could not
delta between themselves).

And you can't condense the list in the general case. It is the set of
refs that we actually want to fetch. We could try passing just the
original refspecs (not the expansion) and letting fetch-pack try to do
the expansion, but in the worst case, you might really just have a
gigantic list of refs.

I think the only sane solution is to write the values to a temporary
file, and do something like:

  git fetch-pack --stateless-rpc --refs-from=$tmpfile

Even if you put the tmpfile in $GIT_DIR, I don't think this should run
afoul of any read-only repositories, since by definition you are
fetching into the repository (but you could also just put it in /tmp).

-Peff