On Tue, Mar 31, 2020 at 07:13:25PM +0200, Josep Torra wrote: > Today I'd noticed a failure in some custom automation that seems to > came as a side effect after of a git client update. > > The issue issue I'd spotted is the following: > > $ git clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic > linux/bionic > Cloning into 'linux/bionic'... > fatal: remote error: Parameters must have values > > Reverting to git 2.17.1 didn't show the issue. > > I'd asked at #git in freenode and @rafasc was able to reproduce and > bisect, pointing to > > https://github.com/git/git/commit/684ceae32dae726c6a5c693b257b156926aba8b7 > > For the time being I'd added `-c protocol.version=0` as a temporary workaround. > > Is this a regression? I'd like to relay the following conversation I had recently: 06:00 <sfr> anyone know why git recently has fetched basically a whole kernel repo when I try to update some trees/branches 06:00 <sfr> this has happened to me for three separate trees over the past few days 06:01 <sfr> none were on git.kernel.org 11:31 <mricon> sfr: if you have an example of the tree/branch that caused you to download a lot for a simple pull, I'd be interested in knowing what it is so I can poke. 16:26 <sfr> mricon: last evening it was fetching the drm tree (git://git.freedesktop.org/git/drm/drm.git branch drm-next): 16:26 <sfr> remote: Enumerating objects: 7237633, done. 16:26 <sfr> remote: Counting objects: 100% (7237633/7237633), done. 16:26 <sfr> remote: Compressing objects: 100% (1069838/1069838), done. 16:26 <sfr> remote: Total 7237633 (delta 6121918), reused 7236008 (delta 6120350) 16:26 <sfr> Receiving objects: 100% (7237633/7237633), 1.32 GiB | 642.00 KiB/s, done. 16:26 <sfr> Resolving deltas: 100% (6121918/6121918), done. 16:26 <sfr> From git://git.freedesktop.org/git/drm/drm 16:26 <sfr> c2556238120bc..700d6ab987f3b drm-next -> drm/drm-next 16:30 <mricon> sfr: interesting. What's your git version? 16:30 <sfr> $ git --version 16:30 <sfr> git version 2.26.0 16:31 <sfr> Debian, so may have some extra patches 16:35 <mricon> sfr: git-2.26.0 switched to protocol v2 by default, so I'm curious if that is what changed 16:35 <mricon> but I've been using protocol v2 for a while now, and I don't see this problem 16:36 <mricon> I also don't yet have git-2.26.0 16:37 <mricon> sfr: if you come across another repo that shows this problem, I suggest you set protocol.version=1 in your .gitconfig to see if that makes any difference 16:37 <sfr> mricon: ok, thanks 16:38 <mricon> total shot in the dark 16:46 <sfr> mricon: that *seems* to make a difference 16:47 <sfr> repo: git://anongit.freedesktop.org/drm/drm-misc branch: for-linux-next 16:48 <sfr> went from trying to transfer 7226542 to just 19 16:48 <sfr> even after I did a reset of the remote branch at my end and a gc 16:49 <sfr> it updated b1e7396a1d0e..98878d9dfc7a 16:50 <sfr> in case it matters, I have "tagopt = --no-tags" set for all the repos I fetch (for obvious reasons) 16:52 <sfr> removing the protocol.version=1 (and resetting/gcing) gets me the bad behaviour again :-( 16:52 <sfr> mricon: so good shot! :-) It appears that there are cases where protocol.version=2 is causing weird results during ref negotiation? -K
