On Sat, Nov 21, 2020 at 09:11:21PM +0100, Martin Ågren wrote: > On Sat, 21 Nov 2020 at 20:37, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > Martin Ågren <martin.agren@xxxxxxxxx> writes: > > > > > On Tue, 17 Nov 2020 at 22:46, Taylor Blau <me@xxxxxxxxxxxx> wrote: > > >> Not very much has changed since last time, but a range-diff is below > > >> nonetheless. The major changes are: > > >> > > >> - Avoid an overflow when bounds checking in the second and third > > >> patches (thanks, Martin, for noticing). > > > > > > FWIW, the updates to patches 2 and 3 look exactly like what I was > > > expecting after the discussion on v1. I have nothing to add. > > > > Thanks, both. Shall we move the topic down to 'next'? > > I really only dug into those patches 2 and 3. I read the rest of the > patches of v1 and went "that makes sense", but that's about it. I > started looking at "pack-bitmap-write: build fewer intermediate bitmaps" > and went "this looks really cool -- I should try to understand this". :-) > > There was SZEDER's comment on that last patch in v2, where future > readers of that patch will have to wonder why it does s/256/270/ in a > test. I agree with SZEDER that the change should be mentioned in the > commit message, even if it's just "unfortunately, we have some magicness > here, plus we want to pass both with SHA-1 and SHA-256; turns out 270 > hits the problem we want to test for". Thanks for reviewing it, and noticing a couple of problems in the earlier patches, too. If folks are happy with the replacement that I sent [1], then I am too :-). I don't think that the "big" patch generated a ton of review on the list, but maybe that's OK. Peff, Stolee, and I all reviewed that patch extensively when deploying it at GitHub (where it has been running since late Summer). > Martin Thanks, Taylor [1]: https://lore.kernel.org/git/X7nMzzMfjm%2Fp9qfj@xnor.local/
