From: Jeff King <firstname.lastname@example.org> To: "Ævar Arnfjörð Bjarmason" <email@example.com> Cc: Duy Nguyen <firstname.lastname@example.org>, Git Mailing List <email@example.com>, Junio C Hamano <firstname.lastname@example.org>, Christian Couder <email@example.com> Subject: Re: git gc --auto yelling at users where a repo legitimately has >6700 loose objects Date: Sat, 13 Jan 2018 05:07:34 -0500 [thread overview] Message-ID: <20180113100734.GA30698@sigill.intra.peff.net> (raw) In-Reply-To: <firstname.lastname@example.org> On Fri, Jan 12, 2018 at 03:44:26PM +0100, Ævar Arnfjörð Bjarmason wrote: > More generally, the reason we even have the 2 week limit is to pick a > good trade-off between performance and not losing someone's work that > they e.g. "git add"-ed but never committed. > > I'm suggesting (but don't know if this is worth it, especially given > Jeff's comments) that one smarter approach might be to track where the > objects came from (e.g. by keeping reflogs for deleted upstream branches > for $expiry_time). I don't think reflogs would help here. We consider reflog'd objects as "reachable". So you'd still have something like this: 1. You delete a branch. Reflog still mentions its commits. 2. You run gc (or auto-gc). Those objects are still retained in the main pack due to the reachability rule. This may happen multiple times, and each time their "timestamp" is updated, because it is really just the timestamp of the containing pack. 3. 30 days later, you run another gc. The reflog is now past its expiration and is deleted, and now those objects are unreachable. This gc turns them loose, but it still considers them "recent" as of the last gc you ran, due to the timestamp thing above. -Peff
next prev parent reply other threads:[~2018-01-13 10:07 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-11 21:33 Ævar Arnfjörð Bjarmason 2018-01-12 12:07 ` Duy Nguyen 2018-01-12 13:41 ` Duy Nguyen 2018-01-12 14:44 ` Ævar Arnfjörð Bjarmason 2018-01-13 10:07 ` Jeff King [this message] 2018-01-12 13:46 ` Jeff King 2018-01-12 14:23 ` Duy Nguyen 2018-01-13 9:58 ` Jeff King 2018-02-08 16:23 ` Ævar Arnfjörð Bjarmason
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 \ --in-reply-to=20180113100734.GA30698@sigill.intra.peff.net \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: git gc --auto yelling at users where a repo legitimately has >6700 loose objects' \ /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).