Workaround: “git push” from msysgit (git for Windows) hangs

This post was written by eli on October 12, 2012
Posted Under: Linux,Software

I had set up my plain git-daemon and everything seemed to work fine, until I tried it from Windows. It just didn’t return from the command. According to a discussion in a newsgroup, the problem is a bug in msysgit’s implementation of side-band-64k, whatever that is.

Personally, even if an upgrade to msysgit existed, or if it was fairly easy to fix this and recompile, I wouldn’t want to take that path: That would require quite a few fixes to make in my case.

So my choice was to fix it on the server. The bug isn’t there, but I can stop the server from announcing that it supports this feature, so the client won’t even try. I don’t know what the impact of disabling this feature is, but it seems like it is about allowing status data for the impatient user to be sent multiplexed with actual object data.

In a xinetd setting, the main daemon calls runs git-daemon when a connection is made, which in turn calls “/usr/bin/git receive-pack” on a push request from the client. Just to make it clear, there is a git-receive-pack executable, but it’s not the one executed. Makes me wonder why it’s there at all.

The git program discloses its capabilities by sending a string saying something like “report-status delete-refs side-band-64k ofs-delta” on the TCP stream (on git version So all that’s needed is to make sure the “side-band-64k” part is not transmitted. I suppose that will influence the way I’ll fetch from remote repositories in the future, but that’s a minor impact (I hope).

The sane way to fix this would be getting the source for git and recompile. I went for hacking the binary directly.

Namely, use XEmacs to open /usr/bin/git for hex editing (after making a backup copy, of course), find the place where that long capability string appears, and change “side-band-64k” to “side-bond-64k”. It’s exactly one byte to fix in the binary file.

And that does the trick. Not the most beautiful workaround, but quick and effective!

I suppose a similar manipulation would work on the client’s executable. But as mentioned above. it’s not effective for me.

Reader Comments

Brilliant – and works on the git.exe client as expected, in which I found and patched five bare “side-band-64K” strings.

Written By Alex on December 6th, 2012 @ 03:09

This worked for me too! Thanks!
The only thing I found confusing is that I had to fix my GIT client. Not the GIT server (where the deamon is running) as your blog suggests.
Fixing it on the GIT server would be even nicer because then I only need to patch 1 instance. Now I need to patch all the clients that are present in my development pool. And after each GIT update I need to patch those clients again.
Or have I mis-understood your post?

Written By Johan on December 12th, 2012 @ 10:56

Ehm, yes. Please read again. I fixed the server, not the client. Even though hex editing the clients is possible, it’s indeed the longer path to go.

Written By eli on December 12th, 2012 @ 11:57

This fixed worked for me. The only tricky thing was to find the correct git executable that the daemon is running on the server.

Written By Andrew MacLeod on February 13th, 2013 @ 13:45

Brilliant !

I’m actually installing GIT into a DNS-323 NAS, arm-based, and i was forced to use SMB or HTTP (but in both cases, the NAS is not really powerful so the workload is important). The funpkg package manager is providing a working GIT package, but impacted by the bug.

Kudos for this solution, elegant and efficient !

Written By Graveen on April 1st, 2014 @ 01:32

I don’t know who you are, but you’re a damned genius.

Thanks for posting this.

Written By Robby on July 23rd, 2014 @ 00:42

This is amazing.
I just used Notepad++ to do a replace on the git.exe.
Thank you!!

Written By Igor on October 13th, 2014 @ 16:06

“git config –global sendpack.sideband false” on client solves the problem (git version 1.9.4.msysgit.2)

Written By Pavel Kosnyrev on December 14th, 2014 @ 16:19

I’m running into the same issue as you guys. I tried both the hex fix and the sideband setting fix. None worked for me =( .

On the server side, the repo is a TFS (Microsoft’s Team Foundation Server) Git repository. What is curious is that Visual Studio can push the repo just fine but the regular git client (1.9.5.msysgit.1) can’t … It seems that the TFS server and the regular git client don’t like each other sometimes.

And this had to happen after months of convincing my dev teammates to switch to Git. Aaaaarrrgggghhh!!!!

Well, this won’t affect devs since we all have VS, but the build guys are freaking out about this since they have had sporadic hangings when cloning repos and we believe the cloning issue is related to this.

Written By Pedro on June 19th, 2015 @ 17:47

Microsoft helped me with this issue and we figured things out! I wrote a blog post about it here

Thanks Eli for posting about this.

Written By Pedro on June 26th, 2015 @ 17:41

Thankyou to the poster of comment #8. I ran into this same problem with git 2.10 on a Windows client and have been pulling my hair out all morning. Using the global config option solved the problem.

Written By Bill on February 14th, 2017 @ 00:32

Thanks also to Pavel the poster of comment #8. Becaause I can’t find anymore “side-band-64k” string.

Note that I had to add manually:

sideband = false

to global .gitconfig, because the command:

$ git config –-global sendpack.sideband false
error: key does not contain a section: –-global

does not work.

Written By thierrybo on August 5th, 2018 @ 10:52

Add a Comment

required, use real name
required, will not be published
optional, your blog address