Release 2.22.0 breaks side-band for git protocol

[bit-bash]

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

Setup

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

$ git --version --build-options

git version 2.22.0.windows.1
cpu: x86_64
built from commit: d003d728ffa6c0006da875ec6318d3f6b28a4ddb
sizeof-long: 4
sizeof-size_t: 8

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

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]

• What options did you set as part of the installation? Or did you choose the
  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

Editor Option: Nano
Custom Editor Path:
Path Option: BashOnly
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Disabled
Enable Symlinks: Disabled
Enable Builtin Interactive Add: Disabled

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

Internally using the git protocol to local git server on Ubuntu 16.04 (running git-daemon).
Running "git config --list" on local system shows:
sendpack.sideband=false
which allowed the git protocol to be used with git v2.21.0 or earlier.

Details

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

bash

• 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 clone git://serverip/project.git
cd project
; make project changes here
git add files-that-changed
git commit
git push  ; git will hang here

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

That the push would have succeeded and not hung.

• What actually happened instead?

The git push command hangs.

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

Will fail on any repo that we access using the git protocol. The SSH protocol is OK.

I looked at the git-for-windows source code and noticed that the code to handle sideband=false is missing in send-pack.c for v2.22.0. This code was present for previous releases of git-for-windows but is no longer there for v2.22.0.

I've attached the commit that is present for v2.21.0 and is NOT present for v2.22.0. The previous commits for send-pack.c are identical so only this last commit is missing.

commit1da059c224cff333d6b53abd80e20533238e7832.txt

[dscho]

I am fairly certain that this is a duplicate of #907.

Maybe you find it in yourself to address the task I outlined in #907 (comment)?

[bit-bash]

I'll look at the task in #907. I'll also test to see if this is working for 32-bit as well.

If it doesn't work for both 32-bit and 64-bit then the issue has not been resolved yet. If it works for 32-bit then 64-bit is still broken.

Just for clarification, if I perform the task in #907 to fix the issue, does that only resolve it for my local install of git-for-windows or is the intent that I push the fix back to github for future releases?

[dscho]

If it doesn't work for both 32-bit and 64-bit then the issue has not been resolved yet. If it works for 32-bit then 64-bit is still broken.

I highly doubt that it is fixed for 64-bit. I think it is currently broken for 32-bit and 64-bit, and that went undetected for a long time because there are no test cases in Git's test suite that run on Windows by default and that would verify that pushing via git:// works (where the sideband is most needed, IIRC?).

Just for clarification, if I perform the task in #907 to fix the issue, does that only resolve it for my local install of git-for-windows or is the intent that I push the fix back to github for future releases?

It will result in a fix that is pushed back to GitHub for future releases.

While it won't fix your local installation, that is easily fixed, though: once your PR is accepted, a new snapshot will be built automatically. These snapshots are functionally equivalent to full releases (code-signed and all), with two notable quirks: the version is a bit funny, and the release notes will reflect the "in-between"-ness.

I consider those snapshots rock solid and safe to use in production. If bugs are encountered in them, I will prioritize bug fixes as much as I will with official releases. Once fixed, the snapshots will get the bug fixes first, of course.

[dscho]

@bit-bash Oh, and I encourage you to move fast with that PR, as I won't have time to work on this issue this year (apart from reviewing and accepting PRs), and v2.23.0 is scheduled for mid-August.

If you're fast enough, you will get that bug fix in Git for Windows v2.23.0.

[dscho]

@kokostek maybe you are interested enough to drive this forward?