On Thu, Mar 15 2018, Junio C. Hamano jotted: > * ti/fetch-everything-local-optim (2018-03-14) 1 commit > - fetch-pack.c: use oidset to check existence of loose object
Looks good to me, and great to have such an optimization in. > * ab/pcre-v2 (2018-03-14) 3 commits > > Will merge to 'next'. > >[...] > > * ab/perl-fixes (2018-03-05) 13 commits > > Will merge to 'master'. Given 2.17-rc1 next Tuesday according to your calendar, what's the status of these two landing in 2.17? I'd like to annoy packagers with all this perl/ stuff in just one release instead of spreading out out over two, and without ab/perl-fixes they'll need another hack to avoid installing our Error.pm. The ab/pcre-v2 is less important, but given the minimal nature of it would be very nice to have in 2.17 as well so we get off the mostly-unmaintained v1 sooner than later. > * nd/repack-keep-pack (2018-03-07) 6 commits > - SQUASH??? > - pack-objects: display progress in get_object_details() > - pack-objects: show some progress when counting kept objects > - gc --auto: exclude base pack if not enough mem to "repack -ad" > - repack: add --keep-pack option > - t7700: have closing quote of a test at the beginning of line > > "git gc" in a large repository takes a lot of time as it considers > to repack all objects into one pack by default. The command has > been taught to pretend as if the largest existing packfile is > marked with ".keep" so that it is left untouched while objects in > other packs and loose ones are repacked. > > Expecting a reroll. > cf. <CACsJy8BW_EtxQvgL=YrCXCQY7cEWCQxgfkeH=Gd=X=uvyhp...@mail.gmail.com> > Except for final finishing touches, this looked more-or-less ready > for 'next'. > > As I noted in 87a7vdqegi....@evledraar.gmail.com and 877eqhq7ha....@evledraar.gmail.com (both at: https://public-inbox.org/git/?q=87a7vdqegi.fsf%40evledraar.gmail.com) I think we should change the too-specific behavior here to be more generic (and am happy to do the work pending feedback from Duy on what he thinks about it). I'm also interested to know from those at Microsoft (CC'd some) if the mechanism I've proposed is something closer to what they could eventually use to gc windows.git. I know that now it doesn't GC now, and they have some side-channel mechanism for pre-deploying large (daily?) packs to clients, if it's adjusted as I suggest gc could be told not to touch packs of that size, leaving only stray small packs from "git pull" and loose objects to GC. I may also have entirely misunderstood how it works, this is from brief in-person conversations at Git Merge. But as far as mainlining some of that eventually I think it would be good to get feedback on whether the mechanism I proposed would get in their way more or less than what Duy has, or be entirely irrelevant because they need something else. Thanks!
