According to a git bisect between the v1.8.4 and v1.8.4.3 tags, it
appears the changes in 5e7dcad, "upload-pack: send non-HEAD symbolic
refs", cause the ref advertisement to fail of the repository has more
than a handful of symbolic refs. Here's a simple reproduce case
(tested on Bash):

Aphrael:example bturner$ git version
git version
Aphrael:symbolic-refs bturner$ git init example
Initialized empty Git repository in /Users/bturner/example/.git/
Aphrael:symbolic-refs bturner$ cd example
Aphrael:example bturner$ echo "Testing..." > file.txt
Aphrael:example bturner$ git add file.txt
Aphrael:example bturner$ git commit -m "Initial commit"
[master (root-commit) b4c4b2a] Initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 file.txt
Aphrael:example bturner$ for ((i=1;i<21;i++)); do git symbolic-ref
refs/heads/syms/$i refs/heads/master; done
Aphrael:example bturner$ git ls-remote .
fatal: protocol error: impossibly long line
fatal: Could not read from remote repository.

A symref= entry is written into the first packet of the ref
advertisement, right after the capabilities, for each symbolic ref in
the repository. Unfortunately, no splitting is done on that value and
so once you have 15-20 symbolic refs (more or less depending on path
lengths), you blow the 996 byte limit in format_packet (pkt-line.c)
and all further clone/fetch operations fail.

I've verified this same issue exists in all 1.8.5 RCs.

Best regards,
Bryan Turner
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to