I have two servers set up (as far as I know) exactly the same. On one of them, committing with git has always been fine, however on the second one, I've started getting this error:
fatal: The remote end hung up unexpectedly
error: error in sideband demultiplexer
Everything is the same between the two, including the contents of the .git/hooks/post-receive
file.
Is there a step in configuration I've missed somewhere, or something? I've tried reinitialising the repo twice now, to no avail.
My post-receive file is as follows:
#!/bin/sh
cd ..
env -i git reset --hard
On this GitHub support thread, this kind of error seems to be related to a repository corruption of some kind.
The issue was fixed by resetting the head of the corrupt remote repo (with git remote set-head
).
Update Nov. 2020, nine+ years later:
With Git 2.30 (Q1 2021), the side-band status report can be sent at the same time as the primary payload multiplexed, but the demultiplexer on the receiving end incorrectly split a single status report into two, which has been corrected.
That could help avoid errors from the "remote end", as seen in the OP.
See commit 712b037 (27 Oct 2020) by Jeff King (peff
).
See commit 8e86cf6, commit 17e7dbb (19 Oct 2020) by Johannes Schindelin (dscho
).
(Merged by Junio C Hamano -- gitster
-- in commit 6b9f509, 02 Nov 2020)
sideband
: avoid reporting incomplete sideband messagesSigned-off-by: Johannes Schindelin
In 2b695ecd74d (t5500: count objects through stderr, not trace, 2020-05-06) we tried to ensure that the "
Total 3
" message could be grepped in Git's output, even if it sometimes got chopped up into multiple lines in the trace machinery.However, the first instance where this mattered now goes through the sideband machinery, where it is still possible for messages to get chopped up: it is possible for the standard error stream to be sent byte-for-byte and hence it can be easily interrupted.
Meaning: it is possible for the single line that we're looking for to be chopped up into multiple sideband packets, with a primary packet being delivered between them.This seems to happen occasionally in the
vs-test
part of our CI builds, i.e. with binaries built using Visual C, but not when building with GCC or clang; The symptom is thatt5500.43
fails to find a line matchingremote: Total 3
in thelog
file, which ends in something along these lines:remote: Tota remote: l 3 (delta 0), reused 0 (delta 0), pack-reused 0
This should not happen, though: we have code in
demultiplex_sideband()
specifically to stitch back together lines that were delivered in separate sideband packets.However, this stitching was broken in a subtle way in fbd76cd450 ("
sideband
: reverse its dependency on pkt-line", 2019-01-16, Git v2.21.0-rc0 -- merge listed in batch #5): before that change, incomplete sideband lines would not be flushed upon receiving a primary packet, but after that patch, they would be.The subtleness of this bug comes from the fact that it is easy to get confused by the ambiguous meaning of the
break
keyword: after writing the primary packet contents, thebreak;
in the original version ofrecv_sideband()
does not break out of thewhile
loop, but instead only ends theswitch
case:while (!retval) { [...] switch (band) { [...] case 1: /* Write the contents of the primary packet */> write_or_die(out, buf + 1, len); /* Here, we do *not* break out of the loop, `retval` is unchanged */ break; ...] } if (outbuf.len) { /* Write any remaining sideband messages lacking a trailing LF */ strbuf_addch(&outbuf, '\n'); xwrite(2, outbuf.buf, outbuf.len); }
In contrast, after fbd76cd450 ("
sideband
: reverse its dependency on pkt-line", 2019-01-16, Git v2.21.0-rc0 -- merge listed in batch #5), the body of thewhile
loop was extracted intodemultiplex_sideband()
, crucially_including
_ the logic to write incomplete sideband messages:switch (band) { [...] case 1: *sideband_type = SIDEBAND_PRIMARY;> /* This does not break out of the loop: the loop is in the caller */> break; ...] } cleanup: [...] /* This logic is now no longer `_outside`_ the loop but `_inside`_ */ if (scratch->len) { strbuf_addch(scratch, '\n'); xwrite(2, scratch->buf, scratch->len); }
The correct way to fix this is to return from
demultiplex_sideband()
early.
The caller will then write out the contents of the primary packet and continue looping.The
scratch
buffer for incomplete sideband messages is owned by that caller, and will continue to accumulate the remainder(s) of those messages.
The loop will only end oncedemultiplex_sideband()
returned non-zero and did not indicate a primary packet, which is the case only when we hit thecleanup:
path, in which we take care of flushing any unfinished sideband messages and release thescratch
buffer.To ensure that this does not get broken again, we introduce a pair of subcommands of the
pkt-line
test helper that specifically chop up the sideband message and squeeze a primary packet into the middle.Final note: The other test case touched by 2b695ecd74d (t5500: count objects through stderr, not trace, 2020-05-06, Git v2.27.0-rc0) is not affected by this issue because the sideband machinery is not involved there.