I get this error message with git version 1.7.5.GIT:
fatal: protocol error: bad line length character:
Git version 1.4.4.4 works fine.
I have read this was a very old problem, and there were some
fixes, then how come I still get this in the latest version of
Git? All the explanations I could find about this bug don't seem
to apply for my case.
How do bugs in Git get solved? I can't find an issue tracker.
Details:
$ export GIT_TRACE=1
$ export GIT_TRACE_PACKET=1
$ git push
trace: built-in: git 'push'
trace: run_command: 'ssh' 'github' 'git-receive-pack '\''pebbe/Gabmap.git'\'''
fatal: protocol error: bad line length character:
The output above comes immediately. When I run the ssh command
listed above, it takes time before I get a response. So even if
Git does run the command, it doesn't wait for a response from
the server.
Setting GIT_TRACE_PACKET doesn't seem to have any effect.
I added some debug code in pkt-line.c, function
packet_read_line(). This tells me that 'buffer' that is passed
to packet_read_line() contains nothing but null characters,
while 'size' is set to 1000.
Running the ssh command as listed by trace works fine:
$ ssh github git-receive-pack 'pebbe/Gabmap.git'
00720444852406fd34c3eb0c8cdcb05cd2af979d2b34 refs/heads/master report-status delete-refs side-band-64k ofs-delta
0000
--
Peter Kleiweg
http://pkleiweg.home.xs4all.nl/
On Tue, Jun 07, 2011 at 06:33:07PM +0200, Peter Kleiweg wrote:
I get this error message with git version 1.7.5.GIT:
fatal: protocol error: bad line length character:
Git version 1.4.4.4 works fine.
I can't reproduce the problem here. Can you try bisecting to find the
commit that introduces the problem?
How do bugs in Git get solved? I can't find an issue tracker.
You send an email to the mailing list and people work on it. :)
Details:
$ export GIT_TRACE=1
$ export GIT_TRACE_PACKET=1
$ git push
trace: built-in: git 'push'
trace: run_command: 'ssh' 'github' 'git-receive-pack '\''pebbe/Gabmap.git'\'''
fatal: protocol error: bad line length character:
Your "ssh github" is weird. Usually that would be "ssh git@github.com",
unless you have set up an alias in .ssh/config. Is that the case? If so,
can you show us the alias? Is it going through a proxy machine or
anything exotic?
Setting GIT_TRACE_PACKET doesn't seem to have any effect.
That's probably because we never get any packets; the very first one is
bogus, and we abort.
I added some debug code in pkt-line.c, function
packet_read_line(). This tells me that 'buffer' that is passed
to packet_read_line() contains nothing but null characters,
while 'size' is set to 1000.
Yeah, it's expecting data to be written into it. You need to see what
packet_read_line reads into linelen via safe_read (which is also printed
in the error message, so it looks from the above like it contains NULs).
Running the ssh command as listed by trace works fine:
$ ssh github git-receive-pack 'pebbe/Gabmap.git'
00720444852406fd34c3eb0c8cdcb05cd2af979d2b34 refs/heads/master report-status delete-refs side-band-64k ofs-delta
0000
That looks normal. I wonder why git is not getting the same data.
-Peff
Jeff King schreef op de 7e dag van de zomermaand van het jaar 2011:
On Tue, Jun 07, 2011 at 06:33:07PM +0200, Peter Kleiweg wrote:
quoted
How do bugs in Git get solved? I can't find an issue tracker.
You send an email to the mailing list and people work on it. :)
Is that git@vger.kernel.org ?
quoted
I added some debug code in pkt-line.c, function
packet_read_line(). This tells me that 'buffer' that is passed
to packet_read_line() contains nothing but null characters,
while 'size' is set to 1000.
Yeah, it's expecting data to be written into it. You need to see what
packet_read_line reads into linelen via safe_read (which is also printed
in the error message, so it looks from the above like it contains NULs).
I made it read some more than 4 bytes. And this is what I get:
{27}]0;github git-receive-pack 'pebbe/Gabmap.git'{7}
Ah, I see! I have a wrapper set-up around ssh that sets the
window title of the shell to the ssh command argument. That is
what messes things up!
OK. Fixed now.
--
Peter Kleiweg
http://pkleiweg.home.xs4all.nl/