Re: Possible regression in git 2.26.0

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Mar 31, 2020, 17:22 UTC
Message-ID: <20200331172218.evsoljccfmjec2mz@chatter.i7.local>
In-Reply-To: <CAE0g23A0+4MPwACTsdjk=eOYaGBDEwsD2t_F072Z33Gb6y2qZw@mail.gmail.com>

On Tue, Mar 31, 2020 at 07:13:25PM +0200, Josep Torra wrote:

Show 20 quoted lines

> 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