Re: Clone fails on a repo with too many heads/tags
- From
Jeff King <peff@peff.net>
- Date
- Mar 18, 2012, 19:07 UTC
- Message-ID
- <20120318190659.GA24829@sigill.intra.peff.net>
- In-Reply-To
- <m3fwd550j3.fsf@localhost.localdomain>
On Sun, Mar 18, 2012 at 09:36:24AM -0700, Jakub Narebski wrote:
Show 11 quoted lines
> > 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