I can see how this would be theoretically possible in the same way I could see using `git filter-branch` to remove one or more commits from a code repository. But as it requires walking back up the tree to recalculate all of the commit hashes based on the new state of your files, I suspect it would be an extremely slow/expensive operation in bup's case. Someone who knows more about bup's internals can correct me if I'm wrong.

true. and actually bup can't use git's tooling directly because of the different use cases it's optimized for. git won't make any use of bup's optimizations: midx (combination of multiple .idx files into a handful of bigger ones to reduce page faults during binary searches) and bloom filter.

git's tools, namely filter-branch and gc have been reported to work on limited-size bup repositories, but it very quickly eats up all ram and cpu and never finishes because of the sheer amount of objects that are usually stored in a bup repository

Isn't this exactly what Obnam does?

I suspect that Obnam doesn't cause all of the de-duplicated chunks to get so "entagled" (as bup puts it, in their readme).

There are existing discussions about the way bup pruning would have to work:

https://groups.google.com/forum/#!searchin/bup-list/prune/bu...

Sounds like they are actually making progress on it.