elmar
backup expiry?
Hi!
Is there a way to expire backups here? I understand git is not particularly well designed to removing past commits and information, but it would be nice to at least acknowledge that fact in the documentation.
Just throwing ideas out there, but i think the following could work... assume the repo is in backup.git:
date=2025-09-10
mv backup.git backup.git.$date
git clone --shallow-since=$date file:///$PWD/backup.git.old backup.git
# eventually, expire the old repos
rm -rf backup.git.$date
this would purge all commits since the given date, at the cost of recloning the entire repository at each rotation. naturally, this could lead to data loss, here's, for example, a run where the date is too far in the future:
anarcat@angela:tmp$ git clone --shallow-since=2025-09-10T12:35:00 file:///$PWD/a d
Cloning into 'd'...
fatal: no commits selected for shallow requests
fatal: the remote end hung up unexpectedly
anarcat@angela:tmp[128]$
... proper error handling should deal with such corner cases.
of course, this means the resulting repository is "grafted" which, at this point, i'm not even sure what it means because, officially, "grafts" are deprecated. yet if you do the above and end up with one extra commit, you end up with this:
anarcat@angela:d$ git log
commit c08104d23f1add8b95b273f2b8c7ff8772b43ff0 (grafted, HEAD -> main, origin/main, origin/HEAD)
Author: Antoine Beaupré <[email protected]>
Date: Wed Sep 10 12:35:56 2025 -0400
101
see the grafted there? no idea what that is: it's not a branch or a tag, it's not even a ref. .git/shallow points at that commit, likely the earliest commit available.
this repository is unusual in a couple of ways, the most noticeable is that the root commit (40 x 0) is entirely missing and can never be retrieved, which could lead to breakage for some tools that try to crawl all the way up to that and are not familiar with shallow clones.
but i think it is, otherwise, a perfectly functional repository.
