From: Jeff King <email@example.com> To: Konstantin Ryabitsev <firstname.lastname@example.org> Cc: Josep Torra <email@example.com>, firstname.lastname@example.org Subject: Re: Possible regression in git 2.26.0 Date: Fri, 10 Apr 2020 17:00:44 -0400 [thread overview] Message-ID: <20200410210044.GA2074620@coredump.intra.peff.net> (raw) In-Reply-To: <email@example.com> On Tue, Mar 31, 2020 at 01:22:18PM -0400, Konstantin Ryabitsev wrote: > 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? Possibly. The underlying negotiation technique is roughly the same, but it's possible there's a subtle difference in the v2 code. I spent a little time trying to reproduce with the branch mentioned above, but couldn't. If somebody hits it again, the most useful thing would be: - a dump of "git for-each-ref" in the client repo - the exact fetch (or pull) command which behaves differently between the two protocols -Peff
next prev parent reply other threads:[~2020-04-10 21:00 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 2020-04-10 21:00 ` Jeff King [this message] 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=20200410210044.GA2074620@coredump.intra.peff.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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).