Git silently broke push-options over ssh?

Hi,

I'm using Git (for Windows) 2.33.1 and using push-options as described on <https://docs.gitlab.com/ee/user/project/push_options.html> does not work any more (IIRC it used to work with Git 2.16 and 2.17).

If I understood <https://opensource.googleblog.com/2018/05/introducing-git-protocol-version-2.html> correctly I have to enable the Git protocol version 2 and then the push options should work.

Now, when I try to use push options on Windows it does not work. I tried to debug it:

D:\TortoiseGit>set GIT_TRACE=2 D:\TortoiseGit>set GIT_SSH=ssh.exe D:\TortoiseGit>set GIT_SSH_VARIANT=ssh D:\TortoiseGit>set GIT_PROTOCOL=version=2 D:\TortoiseGit>git -c protocol.version=2 -c ssh.variant=ssh -c ssh.command=ssh push -v -o ci.skip origin master~23:testing 17:36:06.285346 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/bin 17:36:06.285346 git.c:455 trace: built-in: git push -v -o ci.skip origin 'master~23:testing' Pushing to gitlab.com:tortoisegit/tortoisegit.git 17:36:06.295270 run-command.c:666 trace: run_command: unset GIT_CONFIG_PARAMETERS GIT_PREFIX; ssh.exe git@gitlab.com 'git-receive-pack '\''tortoisegit/tortoisegit.git'\'''

As you can see, the "-o SendEnv" parameter not passed to ssh.exe and, therefore, I think the push option is not transferred to the server.

According to <https://github.com/git-for-windows/git/issues/3486> the reason is a commit that was shipped with Git 2.18 (in 2018):

<https://github.com/git/git/commit/1aa8dded3afff28d8f4c24a97b237a0d9e633173>

How to use push options with Git over SSH?

On Fri, Oct 22, 2021 at 07:27:14PM +0200, Sven Strickroth wrote:

I don't think that is true. There is no v2 push protocol yet, so the push options must work over v0.

Push options don't go through the environment. The GIT_PROTOCOL magic for enabling v2 does, but push options themselves happen over the Git protocol. Try GIT_TRACE_PACKET for seeing the actual conversation. E.g.:

  $ GIT_TRACE_PACKET=1 GIT_TRACE=1 git push -o foo git.peff.net:foo.git
  16:49:19.236448 git.c:455               trace: built-in: git push -o foo git.peff.net:foo.git
  16:49:19.237409 run-command.c:666       trace: run_command: unset GIT_PREFIX; ssh git.peff.net 'git-receive-pack '\''foo.git'\'''
  16:49:19.423323 pkt-line.c:80           packet:         push< b2f0a7f47f5f2aebe1e7fceff19a57de20a78c06 refs/heads/master\0report-status report-status-v2 delete-refs side-band-64k quiet atomic ofs-delta push-options object-format=sha1 agent=git/2.30.2
  16:49:19.423399 pkt-line.c:80           packet:         push< 0000
  16:49:19.431385 pkt-line.c:80           packet:         push> 0000
  16:49:19.431421 pkt-line.c:80           packet:         push> foo
  16:49:19.431442 pkt-line.c:80           packet:         push> 0000
  Everything up-to-date

On the server side, receive-pack will stick them in the environment to communicate them to hooks, etc, but you wouldn't be able to see that from the client.

Do note that I had to set receive.advertisePushOptions on the server to make it work (though if it's not set, the client should complain loudly). If you're pushing to gitlab.com they've presumably set up the server side appropriately.

-Peff

Am 22.10.2021 um 22:53 schrieb Jeff King:

You are right. After enabling GIT_TRACE_PACKET I see that the push-option gets transmitted correctly.

I got confused was because a GitLab CI pipeline run despite I passed ci.skip. The reason why the pipeline ran despite of that flag is that some external push hook triggered a CI pipeline action manually - when I look at GitLab immediately after the push I see that the pipeline is skipped and then the external hook fires...

Thanks for the hint for enabling GIT_TRACE_PACKET Peff and sorry for the noise.

  Sven