On 5/30/2019 11:01 AM, Johannes Schindelin wrote: > Hi Peff, > > On Thu, 30 May 2019, Jeff King wrote: > >> On Wed, May 29, 2019 at 09:53:44AM -0700, Junio C Hamano wrote: >> >>>>> * ds/object-info-for-prefetch-fix (2019-05-28) 1 commit >>>>> - sha1-file: split OBJECT_INFO_FOR_PREFETCH >>>>> >>>>> Code cleanup. >>>>> >>>>> Will merge to 'next'. >>>> >>>> I think this one is actually a bug-fix (we are refusing to prefetch for >>>> "QUICK" calls even though was not the intent), and it is new in this >>>> release. >>>> >>>> I'm not sure of the user-visible impacts, though. There are a lot of >>>> QUICK calls, and I'm not sure for which ones it is important to fetch. >>> >>> Hmph. I took it as primarily futureproofing, as I didn't find a way >>> to trigger bad behaviour from within the current codebase. >> >> Hmm. Looking over the uses of OBJECT_INFO_QUICK, they all seem to be in >> either index-pack or as part of a fetch operation. And in both of those >> cases, we'd disable the whole feature anyway with fetch_if_missing. >> >> So I _think_ you are right, and there isn't a way to trigger it. > > FWIW that was also my impression, but then, I did not look very closely. > > In an attempt to find regressions (and to fix them) during the -rc phase, > we rebased VFSforGit's patches on top of current `master`, and saw this > issue. But yeah, the issue fixed by Stolee's patch seems to be caused by > the interaction between current `master` and the VFSforGit patches. Just to complete the circle, I found this *possible bug* while investigating test failures with VFS for Git, but it turns out it was related to a behavior change in the multi-pack-index and the test we were running only worked by accident before as it was testing a scenario that never occurs in practice. The fix required a change to our VFS for Git test. See [1] for full details if you are interested. So I agree, this is not a priority to ship in 2.22.0. Thanks, -Stolee [1] https://github.com/microsoft/VFSForGit/pull/1213
