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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ivan Todoroski <grnch_lists@xxxxxxx> writes:

> I recently tried cloning a fresh copy of a large repo (converted from CVS, 
> nearly 10 years of history) and to my surprise "git clone" failed with the 
> following message:
> 
>     error: cannot spawn git: No such file or directory
> 
> The problem is only reproduced using the Smart HTTP transport.

[...]
> I tracked down the problem to remote-curl.c:fetch_git(). That's where the 
> "fetch-pack" command line is being constructed with all the refs on one line:
> 
> git fetch-pack --stateless-rpc --lock-pack ...<all the refs>...
> 
> 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).

-- 
Jakub Narebski

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]