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

>
> 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).
>