Closed OpenBagTwo closed 9 months ago
$ cd /path/to/my/minecraft/worlds/backup
$ du -h -d0 .
64G .
$ git gc
$ du -h -d0 .
55GB .
$ gsb delete <17-untagged-backup-hashes>
Could not delete branch gsb:
'Branch not found: gsb'
To permanently delete these backups, run the command:
git gc
$ du -h -d0
55G .
$ git gc
$ du -h -d0 .
55G .
Oh right. Because the original branch wasn't gsb
and was thus not deleted (that was the whole "Could not delete branch gsb" thing) , so those old commits aren't actually orphaned.
$ git branch
* gsb
main
$ git branch -D main
Deleted branch main (was 05a457b2).
$ git gc
$ du -h -d0 .
55G .
:thinking:
one stack exchange later
$ git gc --prune=now
Enumerating objects: 55328, done.
Counting objects: 100% (55328/55328), done.
Delta compression using up to 24 threads
Compressing objects: 100% (17739/17739), done.
Writing objects: 100% (55328/55328), done.
Total 55328 (delta 37312), reused 55328 (delta 37312), pack-reused 0
$ du -h -d0
54G .
After all that back-and-forth that's not hugely impressive, but it is something...
Anyway, clearly the message needs to be updated, because git gc
won't delete diddly for two weeks by default.
Message now reads:
Deleted backups are now marked as "loose." To delete them immediately, run the command:
git gc --aggressive --prune=now
(as tested on my small artificial repo)
I also tested this on one of my coding git repos:
$ du -h -d0 .
98M .
$ git prune
$ du -h -d0 .
88M .
$ git gc --aggressive --prune=now
Enumerating objects: 5391, done.
Counting objects: 100% (5391/5391), done.
Delta compression using up to 24 threads
Compressing objects: 100% (4744/4744), done.
Writing objects: 100% (5391/5391), done.
Total 5391 (delta 3717), reused 819 (delta 0), pack-reused 0
$ du -h -d0 .
62M .
So this confirms that git gc --prune=now
is worth doing over just git prune
(because of all that compression and packing, I guess).
I do like that git prune --dry-run
enumerates all of the loose objects, though...
Summary
Implements #8
List of Changes
gsb delete
which can be used to delete one or more backupsrepo.walk()
)git reset --hard commit && git reset --soft head
) to each subsequent backup that won't be deletedgsb
branch and pointing it to the rewritten branch'sHEAD
git init
(for use in testing)git commit
backup.create_backup
now allows for separately specifying the tag name and commit message (though this is not exposed to the CLI)history.get_history
now has two additional features (again, not exposed to the CLI):_repo_with_history
has been moved toconftest.py
where the expensive module-level fixture can be used globallyroot
fixture is a test-level fixture created by fully copying the repo-with-history so that tests can make additional revisions (or so we can, like, safely test deletions)Tech Debt and Other Concerns
history.get_history
andfastforward.delete_backups
walk the history, it feels like there's room for the core of the implementations to be shared. But at this point I think it's wise to postpone further abstraction until there's another use-casehistory.get_history
calls (and thus two repo-history walks). It feels like this could be done all in one go. This is related to howhistory.get_history
is getting so many non-CLI-facing modifications--at some point soon it seems likely that we'll need to abstract away the innards of theget_history
method into a more flexible, lower level utility.Validation Performed
gsb delete
, in both prompted and argument modes.gsb delete
(no args) in one of my big gsb-managed saves and got the prompt I was expecting.gsb delete
to delete a backup on one of my actual game-save backups, will follow that up by runninggit gc
and will observe that the size of the repo has decreasedPR Type
release
)Checklist:
mkdocs serve
locally and ensured that all API docs and changes I have made to the static pages are rendering correctly, with all links working