{"thread":{"id":"53145","subject":"Possible regression in git 2.26.0","startedAt":"2020-03-31T17:13:30Z","lastAt":"2020-04-10T21:00:47Z","messageCount":8,"participants":["Josep Torra","Konstantin Ryabitsev","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"394424","messageId":"CAE0g23A0+4MPwACTsdjk=eOYaGBDEwsD2t_F072Z33Gb6y2qZw@mail.gmail.com","threadId":"53145","inReplyTo":null,"subject":"Possible regression in git 2.26.0","fromName":"Josep Torra","fromEmail":"n770galaxy@gmail.com","sentAt":"2020-03-31T17:13:25Z","receivedAt":"2020-03-31T17:13:30Z","isPatch":false,"sender":{"key":"n770galaxy@gmail.com","avatar":null},"body":"Today I'd noticed a failure in some custom automation that seems to\ncame as a side effect after of a git client update.\n\nThe issue issue I'd spotted is the following:\n\n$ git clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic\nlinux/bionic\nCloning into 'linux/bionic'...\nfatal: remote error: Parameters must have values\n\nReverting to git 2.17.1 didn't show the issue.\n\nI'd asked at #git in freenode and @rafasc was able to reproduce and\nbisect, pointing to\n\nhttps://github.com/git/git/commit/684ceae32dae726c6a5c693b257b156926aba8b7\n\nFor the time being I'd added `-c protocol.version=0` as a temporary workaround.\n\nIs this a regression?\n\nThanks for looking into this.\n\nJosep Torra\n"},{"id":"394425","messageId":"20200331172218.evsoljccfmjec2mz@chatter.i7.local","threadId":"53145","inReplyTo":"CAE0g23A0+4MPwACTsdjk=eOYaGBDEwsD2t_F072Z33Gb6y2qZw@mail.gmail.com","subject":"Re: Possible regression in git 2.26.0","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2020-03-31T17:22:18Z","receivedAt":"2020-03-31T17:22:28Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Tue, Mar 31, 2020 at 07:13:25PM +0200, Josep Torra wrote:\n> Today I'd noticed a failure in some custom automation that seems to\n> came as a side effect after of a git client update.\n> \n> The issue issue I'd spotted is the following:\n> \n> $ git clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic\n> linux/bionic\n> Cloning into 'linux/bionic'...\n> fatal: remote error: Parameters must have values\n> \n> Reverting to git 2.17.1 didn't show the issue.\n> \n> I'd asked at #git in freenode and @rafasc was able to reproduce and\n> bisect, pointing to\n> \n> https://github.com/git/git/commit/684ceae32dae726c6a5c693b257b156926aba8b7\n> \n> For the time being I'd added `-c protocol.version=0` as a temporary workaround.\n> \n> Is this a regression?\n\nI'd like to relay the following conversation I had recently:\n\n06:00 <sfr> anyone know why git recently has fetched basically a whole kernel\n            repo when I try to update some trees/branches\n06:00 <sfr> this has happened to me for three separate trees over the past few days\n06:01 <sfr> none were on git.kernel.org\n11:31 <mricon> sfr: if you have an example of the tree/branch that caused you to\n               download a lot for a simple pull, I'd be interested in knowing what it\n               is so I can poke.\n16:26 <sfr> mricon: last evening it was fetching the drm tree\n            (git://git.freedesktop.org/git/drm/drm.git branch drm-next):\n16:26 <sfr> remote: Enumerating objects: 7237633, done.\n16:26 <sfr> remote: Counting objects: 100% (7237633/7237633), done.\n16:26 <sfr> remote: Compressing objects: 100% (1069838/1069838), done.\n16:26 <sfr> remote: Total 7237633 (delta 6121918), reused 7236008 (delta 6120350)\n16:26 <sfr> Receiving objects: 100% (7237633/7237633), 1.32 GiB | 642.00 KiB/s, done.\n16:26 <sfr> Resolving deltas: 100% (6121918/6121918), done.\n16:26 <sfr> From git://git.freedesktop.org/git/drm/drm\n16:26 <sfr>    c2556238120bc..700d6ab987f3b  drm-next   -> drm/drm-next\n16:30 <mricon> sfr: interesting. What's your git version?\n16:30 <sfr> $ git --version\n16:30 <sfr> git version 2.26.0\n16:31 <sfr> Debian, so may have some extra patches\n16:35 <mricon> sfr: git-2.26.0 switched to protocol v2 by default, so I'm curious\n               if that is what changed\n16:35 <mricon> but I've been using protocol v2 for a while now, and I don't see\n               this problem\n16:36 <mricon> I also don't yet have git-2.26.0\n16:37 <mricon> sfr: if you come across another repo that shows this problem, \n               I suggest you set protocol.version=1 in your .gitconfig to see\n               if that makes any difference\n16:37 <sfr> mricon: ok, thanks\n16:38 <mricon> total shot in the dark\n16:46 <sfr> mricon: that *seems* to make a difference\n16:47 <sfr> repo: git://anongit.freedesktop.org/drm/drm-misc branch: for-linux-next\n16:48 <sfr> went from trying to transfer 7226542 to just 19\n16:48 <sfr> even after I did a reset of the remote branch at my end and a gc\n16:49 <sfr> it updated b1e7396a1d0e..98878d9dfc7a\n16:50 <sfr> in case it matters, I have \"tagopt = --no-tags\" set for all the repos\n            I fetch (for obvious reasons)\n16:52 <sfr> removing the protocol.version=1 (and resetting/gcing) gets me the bad \n            behaviour again :-(\n16:52 <sfr> mricon: so good shot! :-)\n\nIt appears that there are cases where protocol.version=2 is causing \nweird results during ref negotiation?\n\n-K\n"},{"id":"394686","messageId":"20200403185804.GA659704@coredump.intra.peff.net","threadId":"53145","inReplyTo":"CAE0g23A0+4MPwACTsdjk=eOYaGBDEwsD2t_F072Z33Gb6y2qZw@mail.gmail.com","subject":"Re: Possible regression in git 2.26.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-04-03T18:58:04Z","receivedAt":"2020-04-03T18:58:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 31, 2020 at 07:13:25PM +0200, Josep Torra wrote:\n\n> Today I'd noticed a failure in some custom automation that seems to\n> came as a side effect after of a git client update.\n> \n> The issue issue I'd spotted is the following:\n> \n> $ git clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic\n> linux/bionic\n> Cloning into 'linux/bionic'...\n> fatal: remote error: Parameters must have values\n\nI can reproduce here, and it's definitely related to using protocol v2.\nRunning:\n\n  GIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote \\\n    git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic \\\n    >/dev/null\n\nyields:\n\n  [...]git> git-upload-pack ~ubuntu-kernel/ubuntu/+source/linux/+git/bionic\\0host=git.launchpad.net\\0\\0version=2\\0\n  [...]git< ERR Parameters must have values\n\nSo it's complaining at that initial contact probing for v2. The behavior\nis the same with v1 (which was an interim step between v0 and v1 to do\nthis probing and check for compatibility).\n\nWe checked that the probe works sensibly against old versions of Git, as\nwell as a few others (JGit, and I can't remember the rest).\n\nDo you know what software powers git.launchpad.net? That \"Parameters\nmust have values\" message has never appeared in any Git version, though\nthe server claims to be v2.17.1:\n\n  $ GIT_TRACE_PACKET=1 git -c protocol.version=0 ls-remote \\\n     git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic \\\n     2>&1 >/dev/null | grep agent=\n  [...]git< a78d21bd8bb58c158f73108eb7d7402619fcae3d HEAD\\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/2.17.1\n\nMy guess is that it may be v2.17.1 with some kind of load-balancing or\nproxy layer in it. It's rather unfortunate that nobody noticed the\nproblem during the year and a half testing phase. But at this point, I\nthink the best path forward is probably to try to fix that server side\n(preferably to speak v2, but if not, to at least ignore the v2 probe\nmarker and continue to speak v0; the client will gracefully handle\nthat).\n\nBy the way, swapping out git:// for https:// in the URL works just fine\nfor this server. In git-over-http, the v2 probe goes in an HTTP request\nheader, and they seem to ignore that and speak v0 (which is an expected\nand fine outcome for pre-v2-aware servers). That may be why nobody\nnoticed before.\n\n-Peff\n"},{"id":"394689","messageId":"20200403193644.GA662633@coredump.intra.peff.net","threadId":"53145","inReplyTo":"20200403185804.GA659704@coredump.intra.peff.net","subject":"Re: Possible regression in git 2.26.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-04-03T19:36:44Z","receivedAt":"2020-04-03T19:36:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 03, 2020 at 02:58:04PM -0400, Jeff King wrote:\n\n> Do you know what software powers git.launchpad.net? That \"Parameters\n> must have values\" message has never appeared in any Git version, though\n> the server claims to be v2.17.1:\n\nI guess it's this:\n\n  https://code.launchpad.net/launchpad\n\nbut I can't find any trace of the \"Parameters must have values\" error\nmessage in there. It looks like it builds on dulwich, but I can't find\nthe message there either. So I'm at a loss.\n\n-Peff\n"},{"id":"394694","messageId":"xmqq8sjcz6pd.fsf@gitster.c.googlers.com","threadId":"53145","inReplyTo":"20200403193644.GA662633@coredump.intra.peff.net","subject":"Re: Possible regression in git 2.26.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-03T19:53:50Z","receivedAt":"2020-04-03T19:53:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I guess it's this:\n>\n>   https://code.launchpad.net/launchpad\n>\n> but I can't find any trace of the \"Parameters must have values\" error\n> message in there. It looks like it builds on dulwich, but I can't find\n> the message there either. So I'm at a loss.\n\nLet me apologize in advance for a totally useless distraction, but\nnevertheless I found it funny.  My search engine found\n\n    https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19780010630.pdf\n\nwhen I asked\n\n    launchpad \"parameters must have values\"\n\nhttps://www.google.com/search?q=launchpad+%22parameters+must+have+values%22\n\n;-)\n"},{"id":"394779","messageId":"20200404152032.GC679473@coredump.intra.peff.net","threadId":"53145","inReplyTo":"xmqq8sjcz6pd.fsf@gitster.c.googlers.com","subject":"Re: Possible regression in git 2.26.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-04-04T15:20:32Z","receivedAt":"2020-04-04T15:20:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 03, 2020 at 12:53:50PM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > I guess it's this:\n> >\n> >   https://code.launchpad.net/launchpad\n> >\n> > but I can't find any trace of the \"Parameters must have values\" error\n> > message in there. It looks like it builds on dulwich, but I can't find\n> > the message there either. So I'm at a loss.\n> \n> Let me apologize in advance for a totally useless distraction, but\n> nevertheless I found it funny.  My search engine found\n> \n>     https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19780010630.pdf\n> \n> when I asked\n> \n>     launchpad \"parameters must have values\"\n\nHeh, wow. I knew vaguely what to expect from the URL, but was quite\npleased to see a PDF full of scanned FORTRAN code. I have a new\nappreciation for working with our newfangled \"C\" code.\n\nI also searched for that error but didn't come up with much. It seems to\nbe common in some AWS workflows. I wonder if it's just coincidence, or\nif launchpad's git:// support is somehow just proxying to a service run\nthrough AWS.\n\nI think the next step is to report it to launchpad folks and let them\nfigure it out. I opened a bug there:\n\n  https://bugs.launchpad.net/launchpad/+bug/1870804\n\n-Peff\n"},{"id":"394957","messageId":"20200407145232.GA1839328@coredump.intra.peff.net","threadId":"53145","inReplyTo":"20200404152032.GC679473@coredump.intra.peff.net","subject":"Re: Possible regression in git 2.26.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-04-07T14:52:32Z","receivedAt":"2020-04-07T14:52:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Apr 04, 2020 at 11:20:33AM -0400, Jeff King wrote:\n\n> I think the next step is to report it to launchpad folks and let them\n> figure it out. I opened a bug there:\n> \n>   https://bugs.launchpad.net/launchpad/+bug/1870804\n\nLooks like this is now fixed:\n\n  https://bugs.launchpad.net/turnip/+bug/1870080\n\n-Peff\n"},{"id":"395242","messageId":"20200410210044.GA2074620@coredump.intra.peff.net","threadId":"53145","inReplyTo":"20200331172218.evsoljccfmjec2mz@chatter.i7.local","subject":"Re: Possible regression in git 2.26.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-04-10T21:00:44Z","receivedAt":"2020-04-10T21:00:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 31, 2020 at 01:22:18PM -0400, Konstantin Ryabitsev wrote:\n\n> 16:47 <sfr> repo: git://anongit.freedesktop.org/drm/drm-misc branch: for-linux-next\n> 16:48 <sfr> went from trying to transfer 7226542 to just 19\n> 16:48 <sfr> even after I did a reset of the remote branch at my end and a gc\n> 16:49 <sfr> it updated b1e7396a1d0e..98878d9dfc7a\n> 16:50 <sfr> in case it matters, I have \"tagopt = --no-tags\" set for all the repos\n>             I fetch (for obvious reasons)\n> 16:52 <sfr> removing the protocol.version=1 (and resetting/gcing) gets me the bad \n>             behaviour again :-(\n> 16:52 <sfr> mricon: so good shot! :-)\n> \n> It appears that there are cases where protocol.version=2 is causing \n> weird results during ref negotiation?\n\nPossibly. The underlying negotiation technique is roughly the same, but\nit's possible there's a subtle difference in the v2 code.\n\nI spent a little time trying to reproduce with the branch mentioned\nabove, but couldn't. If somebody hits it again, the most useful thing\nwould be:\n\n  - a dump of \"git for-each-ref\" in the client repo\n\n  - the exact fetch (or pull) command which behaves differently between\n    the two protocols\n\n-Peff\n"}]}