Taylor Blau <me@xxxxxxxxxxxx> 于2024年12月24日周二 23:39写道： > > On Tue, Dec 24, 2024 at 08:07:16PM +0800, ZheNing Hu wrote: > > I am trying to use the --cruft feature of git gc, and everything works > > well, but when I combine it with --prune=now, I notice that no cruft > > package is generated, which is very strange. So I turned on trace and > > checked: instead of executing `git repack --cruft`, it executed `git > > repack -d -l -a`. Is this normal? If `git gc --cruft --prune=now` > > doesn't work as expected, it won't be safe to further execute `git gc > > --cruft --expire-to=<dir> --prune=now`(in my another patch). > > > > I checked the code, and it appears that add_repack_all_option() first > > processes `--prune=now` before handling `--cruft` option. > > That's right, since --prune=now will cause your repository to purge any > unreachable objects immediately, regardless of their mtimes. > > So after a 'git gc --prune=now', your repository will only consist of > reachable objects, meaning that there will be nothing to put into a > cruft pack. > > Note that 'git gc' does not support the '--expire-to' option, but you > can use it via 'git repack'. > 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). > Thanks, > Taylor Thanks, ZheNing Hu
