From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dominique Martinet Subject: Re: Re: BUG: corrupted list in p9_read_work Date: Thu, 11 Oct 2018 00:55:39 +0200 Message-ID: <20181010225539.GD788@nautica> References: <20181010144855.GB20918@nautica> <00000000000010889e0577e0f5f2@google.com> <20181010160022.GD20918@nautica> <20181010161003.GA5371@nautica> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: syzbot , David Miller , Eric Van Hensbergen , LKML , Latchesar Ionkov , netdev , Ron Minnich , syzkaller-bugs , v9fs-developer@lists.sourceforge.net To: Dmitry Vyukov Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Dmitry Vyukov wrote on Wed, Oct 10, 2018: > yeeeep, this is bug: > https://github.com/google/syzkaller/issues/728 Yeah, it makes sense ; I just had to stumble on it once :) > Turns out git fetch of a named remote and just a tree work > differently. The latter only fetches the main branch. > > 'git fetch ' is it a thing? Is it something that requires > special server configuration? I remember something similar that wasn't > able to fetch a random commit hash all the time... With my version of git (2.19.1); this works with a local tree (git fetch /path/to/repo ref) and with a github remote, but not with a gitolite remote ; I don't think it's safe to assume it'll always work, but it can work. > The plan was to make a named remote and then fetch it, this should > fetch everything. Yeah, that's less efficient but that'd fetch all named branches at least; probably safer than what I tried :) Anyway, the fix seems to be a hit, so cool! Thanks! -- Dominique