[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Oct 2018 00:55:39 +0200
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: syzbot <syzbot+2222c34dc40b515f30dc@...kaller.appspotmail.com>,
David Miller <davem@...emloft.net>,
Eric Van Hensbergen <ericvh@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Latchesar Ionkov <lucho@...kov.net>,
netdev <netdev@...r.kernel.org>,
Ron Minnich <rminnich@...dia.gov>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
v9fs-developer@...ts.sourceforge.net
Subject: Re: Re: BUG: corrupted list in p9_read_work
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 <repo> <hash>' 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
Powered by blists - more mailing lists