Jeff King <peff@xxxxxxxx> 于2024年12月26日周四 23:23写道： > > On Thu, Dec 26, 2024 at 02:19:56PM +0800, ZheNing Hu wrote: > > > 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). > You're right. Only when using `--cruft` and `--expire-to=<dir>` in git-gc, the behavior of `--prune=now` should change: it should pass `--cruft-expiration=now` to repack instead of passing `-a`. I will cc you in the patch for supporting --expired-to=<dir> in git gc. Thank you :) > -Peff -- ZheNing Hu
