From: Ivan Todoroski <grnch_lists@gmx.net>
To: git@vger.kernel.org
Subject: Clone fails on a repo with too many heads/tags
Date: Sun, 18 Mar 2012 08:14:30 +0000 (UTC) [thread overview]
Message-ID: <loom.20120318T083216-96@post.gmane.org> (raw)
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 used msysGit on Windows so my first instinct was to contact them, but after
some poking around I discovered that the problem is present in the Linux
version too, although harder to trigger.
Try executing this script:
-------------------------------
git init too-many-refs
cd too-many-refs
echo bla > bla.txt
git add .
git commit -m test
sha=$(git rev-parse HEAD)
for ((i=0; i<100000; i++)); do
echo $sha refs/tags/artificially-long-tag-name-to-more-easily-
demonstrate-the-problem-$i >> .git/packed-refs
done
-------------------------------
Now share this repo using the Smart HTTP transport (git-http-backend) and then
try cloning it in a different directory. This is what you would get:
$ git clone http://localhost/.../too-many-refs/.git
Cloning into 'too-many-refs'...
fatal: cannot exec 'fetch-pack': Argument list too long
So we come to the real reason for the failure: somewhere inside Git a
subcommand is invoked with all the tags/heads on the command line and if you
have enough of them it overflows the command line length limit of the OS.
Obviously the number of tags in the "too-many-refs" repo above is absurd (100k)
because the cmdline length in Linux is much more generous, but on Windows the
clone fails with as little as 500 tags in the above loop! I am already hitting
this problem with msysGit on real repos, not just artificial test cases.
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>...
next reply other threads:[~2012-03-18 10:10 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-18 8:14 Ivan Todoroski [this message]
2012-03-18 11:37 ` Clone fails on a repo with too many heads/tags Ivan Todoroski
2012-03-18 12:04 ` Nguyen Thai Ngoc Duy
2012-03-18 16:36 ` Jakub Narebski
2012-03-18 19:07 ` Jeff King
2012-03-18 22:07 ` Jakub Narebski
2012-03-19 2:32 ` Jeff King
2012-03-19 2:43 ` Nguyen Thai Ngoc Duy
2012-03-19 2:45 ` Jeff King
2012-03-19 1:05 ` Ivan Todoroski
2012-03-19 1:30 ` Nguyen Thai Ngoc Duy
2012-03-19 2:44 ` Jeff King
2012-03-21 11:05 ` Ivan Todoroski
2012-03-21 14:28 ` Shawn Pearce
2012-03-21 17:14 ` Jeff King
2012-03-21 17:59 ` Jakub Narebski
2012-03-21 20:02 ` Ivan Todoroski
2012-03-21 20:17 ` Jeff King
2012-03-24 20:49 ` Ivan Todoroski
2012-03-25 1:06 ` Jeff King
2012-03-25 2:32 ` Jeff King
2012-03-25 17:33 ` Ivan Todoroski
2012-03-25 17:54 ` Ivan Todoroski
2012-03-26 17:33 ` Jeff King
2012-03-27 7:07 ` Ivan Todoroski
2012-03-25 15:30 ` Ivan Todoroski
2012-03-24 20:53 ` [PATCH/RFC 1/2] fetch-pack: new option to read refs from stdin Ivan Todoroski
2012-03-25 1:19 ` Jeff King
2012-03-25 9:39 ` Ivan Todoroski
2012-03-25 15:15 ` Ivan Todoroski
2012-03-25 20:00 ` Ivan Todoroski
2012-03-26 17:21 ` Jeff King
2012-03-26 17:49 ` Ivan Todoroski
2012-03-26 17:51 ` Jeff King
2012-03-24 20:54 ` [PATCH/RFC 2/2] remote-curl: send the refs to fetch-pack on stdin Ivan Todoroski
2012-03-25 1:24 ` Jeff King
2012-03-25 9:52 ` Ivan Todoroski
2012-03-26 17:24 ` Jeff King
2012-03-27 6:23 ` [PATCH/RFC v2 0/4] Fix fetch-pack command line overflow during clone Ivan Todoroski
2012-03-27 6:25 ` [PATCH/RFC v2 1/4] fetch-pack: new --stdin option to read refs from stdin Ivan Todoroski
2012-03-27 16:59 ` Junio C Hamano
2012-03-27 23:18 ` Ivan Todoroski
2012-03-27 23:26 ` Junio C Hamano
2012-03-27 23:48 ` Ivan Todoroski
2012-03-27 6:26 ` [PATCH/RFC v2 2/4] remote-curl: send the refs to fetch-pack on stdin Ivan Todoroski
2012-03-27 17:18 ` Junio C Hamano
2012-03-27 23:20 ` Ivan Todoroski
2012-03-27 6:27 ` [PATCH/RFC v2 3/4] fetch-pack: test cases for the new --stdin option Ivan Todoroski
2012-03-27 17:40 ` Junio C Hamano
2012-03-27 23:36 ` Ivan Todoroski
2012-03-27 23:43 ` Junio C Hamano
2012-03-28 0:14 ` Ivan Todoroski
2012-03-27 6:28 ` [PATCH/RFC v2 4/4] remote-curl: main test case for the OS command line overflow Ivan Todoroski
2012-03-27 17:43 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20120318T083216-96@post.gmane.org \
--to=grnch_lists@gmx.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).