From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 30E421F45A for ; Tue, 21 Apr 2020 05:19:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726364AbgDUFTA (ORCPT ); Tue, 21 Apr 2020 01:19:00 -0400 Received: from mga04.intel.com ([192.55.52.120]:34484 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725881AbgDUFS7 (ORCPT ); Tue, 21 Apr 2020 01:18:59 -0400 IronPort-SDR: X8VaIHS2vXfiPAi+4PJN5XoGOhIeDU1dN1dMNt+OSyxiv7xgmEF4shaQmb6m/j9Uo7K5px2wNa jOy1qasFcfgQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2020 22:18:59 -0700 IronPort-SDR: a8p1RI9+xbMHCiVBTZaBZVZTZqPWo24j6Qzwz/M9o9/32DqA3IDDN1frd1PG2Vs0oQH+ecW409 mUgXCibO8/qQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,409,1580803200"; d="scan'208";a="244055124" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.213.178.200]) by orsmga007.jf.intel.com with ESMTP; 20 Apr 2020 22:18:59 -0700 Date: Mon, 20 Apr 2020 22:18:58 -0700 Message-ID: <87a735e7r1.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Dixit, Ashutosh" , Subject: Re: Bug in 2.26: git-fetch fetching too many objects? In-Reply-To: <20200420170301.h65vkk36avnud7z3@chatter.i7.local> References: <878siqxiu0.wl-ashutosh.dixit@intel.com> <20200420170301.h65vkk36avnud7z3@chatter.i7.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Mon, 20 Apr 2020 10:03:01 -0700, Konstantin Ryabitsev wrote: > > On Mon, Apr 20, 2020 at 08:44:39AM -0700, Dixit, Ashutosh wrote: > > I am seeing a strange behavior in git-fetch in 2.26. I frequently fetch > > from a couple of linux kernel remotes (so you will have an idea how big the > > repo is). I have a different system with 2.20 on which I never see a > > problem. > > > > So let us say I fetch with 2.20 and it fetches say 20,000 objects. However > > with 2.26 it starts fetching millions of objects, objects which are already > > present locally. I don't know yet if this happens each time or only once in > > a while, I have seen it happen twice, will keep an eye out for this. > > > > If you open a bug please let me know and I can update it with my > > findings. Unless it is a known issue, perhaps already fixed? > > It's a known issue with protocol v2, but nobody's been able to properly > reproduce it in order to debug. If you can reliably make it reoccur, > then please make a copy of your local tree and share with this list, > together with your gitconfig and the remote you're pulling. > > Setting protocol.version=1 should fix it, but if you are willing to help > troubleshoot it, a bunch of people will be super thankful to you for > that, as it affects quite a number of kernel developers. I will see what I can do. I think I am seeing an instance where a branch has incorrect SHA's during the clone itself but I haven't been able to reproduce it after the HEAD moved at the remote. I'll report back if I have a reliable reproducer. Thanks!