3 ms·
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. B
by Smudge 12y ago
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.
- anoother 12y agoIsn't this exactly what Obnam does?
- Smudge 12y agoI 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/bup-list/86j9ovQ-TaI/NOZPfOAu8WkJ https://groups.google.com/forum/#!searchin/bup-list/prune/bu... Sounds like they are actually making progress on it.
- lelutin 12y agotrue. 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