git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Josep Torra <n770galaxy@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Possible regression in git 2.26.0
Date: Tue, 31 Mar 2020 13:22:18 -0400	[thread overview]
Message-ID: <20200331172218.evsoljccfmjec2mz@chatter.i7.local> (raw)
In-Reply-To: <CAE0g23A0+4MPwACTsdjk=eOYaGBDEwsD2t_F072Z33Gb6y2qZw@mail.gmail.com>

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

  reply	other threads:[~2020-03-31 17:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31 17:13 Josep Torra
2020-03-31 17:22 ` Konstantin Ryabitsev [this message]
2020-04-10 21:00   ` Jeff King
2020-04-03 18:58 ` Jeff King
2020-04-03 19:36   ` Jeff King
2020-04-03 19:53     ` Junio C Hamano
2020-04-04 15:20       ` Jeff King
2020-04-07 14:52         ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200331172218.evsoljccfmjec2mz@chatter.i7.local \
    --to=konstantin@linuxfoundation.org \
    --cc=git@vger.kernel.org \
    --cc=n770galaxy@gmail.com \
    --subject='Re: Possible regression in git 2.26.0' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).