Git Push Not working for git:// protocol servers

[johnnyb]

• I was not able to find an open
  or closed issue
  matching what I'm seeing

There appears to be some bug when pushing to git:// protocol for repositories. I believe this is a carryover from msys-git, but no one has logged a bug in the new system. This URL ( http://pete.akeo.ie/2011/07/git-remote-repository.html ) refers to the bug, and said it was bug 457 in the old system. However, the page that it references is now gone now that you all have moved to github.

I searched this issue tracker for the issue but was unable to find it. Anyway, the report is below. I am working around the issue by pushing to a Mac laptop that can then push to the server.

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
  2.10.1.windows.1 64-bit

$ git --version --build-options
git version 2.10.1.windows.1
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
  Windows 10 64-bit

$ cmd.exe /c ver
Microsoft Windows [Version 10.0.14393]

• What options did you set as part of the installation? Or did you choose the
  defaults?
  defaults

# One of the following:

> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> $ cat /etc/install-options.txt
> Path Option: CmdTools
> SSH Option: OpenSSH
> CRLF Option: CRLFAlways
> Bash Terminal Option: ConHost
> Performance Tweaks FSCache: Enabled
> 
> 

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

  None - just did a fresh install to be sure

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

  CMD I believe, but I'm used to UNIX-y environments so I'm a bit out of sorts.

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git push --set-upstream origin master
This occurs when origin is set to the "git://" protocol.

• What did you expect to occur after running these commands?

  I expected it to push

• What actually happened instead?

  It gets stuck "Writing Objects". Depending on the particular push, it may get a different percentage of the way done.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

  It is an internal repository of a client of mine, so no.

[johnnyb]

I was searching google and I found that this bug is shown in Bug 89 of msysgit on github:

msysgit/msysgit#89 (comment)

The workaround, which is shown in the code but not in the thread itself, is to do:

git config --global sendpack.sideband false

Perhaps this would be a good global setting for the installer to set? Since this is essentially undocumented (or at least unpublicized), having a default-working configuration seems to be the best plan of action, unless it breaks something.

[dscho]

@johnnyb is this still the case with Git for Windows v2.21.0 that you cannot push via git:// unless you set sendpack.sideband?

I ask because we're about to release v2.22.0, and we dropped support for that config setting under the assumption that it is no longer necessary.

[johnnyb]

I will try to test it out this week and double-check.

[dscho]

v2.22.0 is already out. With the config setting in question removed.

Hopefully your tests come back saying that it's no longer needed. Because otherwise, we're a little late.

[RoboMWM]

This option is still required for pushing over git://

After trying to figure out why this option was working intermittently I discovered we had two different versions of git bash installed, with the option (and thus no hanging) only working in the older version.

[RoboMWM]

Mingw64 is what shows up in the prompt, and the Git directory is in the 64 bit program files directory, in case that matters (as I noticed some commits related to this).

Not sure where the discussion occurred that assumed this wasn't needed - my guess is that the same steps used to reproduce the bug would show it still exists.

[dscho]

Mingw64 is what shows up in the prompt, and the Git directory is in the 64 bit program files directory, in case that matters (as I noticed some commits related to this).

I do not understand. Could you explain this in more detail?

Not sure where the discussion occurred that assumed this wasn't needed - my guess is that the same steps used to reproduce the bug would show it still exists.

I think I relied on the test suite to catch this, but having had a quick look, we skip the git:// related tests on Windows because the way they are implemented require FIFOs which we cannot use (there is a FIFO emulation in MSYS2 that allows mkfifo to succeed, but git.exe cannot use them, being unaware of any MSYS2-emulated POSIX stuff).

Maybe you could re-introduce 1da059c via a PR and add a test case that does not require FIFOs?

[RoboMWM]

Re Mingw64, I saw a commit message about the issue not showing up in mingw-w64 gitgitgadget@4f9dd21

I'm not a C developer nor am I familiar with the internals of this project so I'm not sure where I'd start for making a PR :/

[dscho]

Re Mingw64, I saw a commit message about the issue not showing up in mingw-w64 gitgitgadget@4f9dd21

If you experience this issue with a 64-bit version of Git for Windows, then mingw-w64 is affected.

I'm not a C developer nor am I familiar with the internals of this project so I'm not sure where I'd start for making a PR

You will have to

• install Git for Windows' SDK
• sdk cd git
• cherry-pick --signoff the commit you already found
• make -j8 install to build it and install it into your SDK
• verify that it fixes your issue (by running commands in the Git SDK Bash)
• preferably provide as PR description a detailed account how to reproduce the issue with Git for Windows, starting from an empty repository.
• fork this repository if you have not done so yet,
• push the branch with the fix
• open the PR here.

It is not exactly as easy as buying an apple pie. On the positive side, it will get you what you want, as quickly as you can make it so.

[assarbad]

I will try to take care of this throughout this week. Let's see how quickly I can send a PR. Issue affects me as well, so reason enough to contribute.

@dscho how do you ensure that this will stick around? Will it also be sent to upstream Git or will it be local to Git for Windows?

Edit: regarding PRs, do you have any guidelines? Signed commits or so? Rebased and squashed to a single commit? Do I also have to test with the 32-bit SDK or can I rely on your CI setup?

[PhilipOakley]

re your edit:

regarding PRs, do you have any guidelines? Signed commits or so? Rebased and squashed to a single commit? Do I also have to test with the 32-bit SDK or can I rely on your CI setup?

Signed commits, small simple steps, usually start at current master, and keep the base constant, though watching for conflicts on next/pu.

See https://github.com/git-for-windows/git/blob/master/CONTRIBUTING.md and SubmittingPatches.

The patches do stick around and eventually get up-streamed, especially when battle tested.

[dscho]

how do you ensure that this will stick around?

Via that regression test you planned on implementing ;-)

Will it also be sent to upstream Git or will it be local to Git for Windows?

It was already sent to the Git mailing list: gitgitgadget#137 (due to the missing regression test, I was under the impression that it was no longer necessary in Git for Windows).

So as soon as you come up with that resurrection accompanied by a regression test, I will be working towards getting this into upstream Git, too.

As to PRs, there were a couple good ones recently that were merged. Maybe they illustrate the shape we like PRs to be in?

[assarbad]

Hehe, alright. Sounds like a plan.

One more question: are there any resources about the research so far into what goes wrong on Windows? The symptom appears to be pretty much a deadlock situation. As I understand it has to do with two "concurrently" issued requests on a single socket? Any references/pointers I can look into to get me started? I'd rather try to tackle (mid term) the underlying issue.

This sounds like a tricky problem that could use some loving care ;-)

Also, I'll have a look at previous PRs as well. Already read through large parts of the documentation linked before, but since there are plenty of cross-references elsewhere, it's a bit tedious.