From: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org> To: Junio C Hamano <email@example.com> Cc: firstname.lastname@example.org, Duy Nguyen <email@example.com>, Takuto Ikuta <firstname.lastname@example.org>, email@example.com, Derrick Stolee <firstname.lastname@example.org>, Ben Peart <email@example.com> Subject: Re: What's cooking in git.git (Mar 2018, #03; Wed, 14) Date: Thu, 15 Mar 2018 09:36:22 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> 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=uVYhPJcw@mail.gmail.com> > Except for final finishing touches, this looked more-or-less ready > for 'next'. > > As I noted in firstname.lastname@example.org and email@example.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!
next prev parent reply other threads:[~2018-03-15 8:36 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-15 1:34 Junio C Hamano 2018-03-15 6:30 ` Duy Nguyen 2018-03-15 16:54 ` Junio C Hamano 2018-03-15 8:36 ` Ævar Arnfjörð Bjarmason [this message] 2018-03-15 17:33 ` Junio C Hamano 2018-03-19 21:16 ` Derrick Stolee 2018-03-15 19:18 ` Lars Schneider 2018-03-15 23:00 ` Lars Schneider 2018-03-16 0:54 ` Junio C Hamano 2018-03-16 21:31 ` Jonathan Tan 2018-03-16 21:52 ` Junio C Hamano 2018-03-16 22:08 ` Jonathan Nieder 2018-03-17 0:53 ` Junio C Hamano
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: What'\''s cooking in git.git (Mar 2018, #03; Wed, 14)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).