Re: [Possible Bug] --cruft option not work with git gc --prune=now

From: Jeff King <peff@peff.net>
Date: Dec 26, 2024, 15:23 UTC
Message-ID: <20241226152347.GA68791@coredump.intra.peff.net>
In-Reply-To: <CAOLTT8TraRjBObcLotNr7+a9Ap7Fy8VVy7HjHLLWwEB_LvBrUQ@mail.gmail.com>

On Thu, Dec 26, 2024 at 02:19:56PM +0800, ZheNing Hu wrote:

Show 7 quoted lines

> Okay, I know that gc doesn't have an --expire-to parameter,
> but here I was hoping to use git gc --prune=now --expire-to=<dir>,
> where expired and unreachable objects would be stored in <dir> for
> easy recovery in case of repository corruption. Moreover, it's more
> convenient compared to using git repack + git prune
> (isn't a single gc command much simpler? Plus, most users are
> likely familiar with gc rather than repack and prune).

I don't think there is any reason that gc _can't_ support --expire-to as you want. But any patch to do so would have to adjust how it calls git-repack.

Up until now, "--prune=now" meant it was fine to run "repack -ad", since that would just discard any unreachable packed objects without further consideration. If we're keeping any objects, then we have to tell repack what to do with them (which traditionally was just passing --unpack-unreachable, but these days can include --cruft).

With --expire-to, that logic wouldn't be valid anymore; even if we are expiring all objects, we still might want to tell repack where to put the expired ones. So I think you'd want to adjust the if/else in add_repack_all_option() to pass --cruft, etc, when you see --expire-to (but still continue to "repack -ad" otherwise to keep the traditional "git gc --prune=now" as cheap as possible).

-Peff