You're running the BFG to remove big files from your repository.
There are some big files in your HEAD commit (ie 'protected') and so the BFG is not removing those files from that commit.
However, those files are also in some previous commits. The BFG is removing the files from those older commits, and you'd prefer for it to not do that - you'd like the history of those files to remain intact.
Git really doesn't track files, it tracks content. So when the BFG 'protects a file' in your HEAD commit, it's definitely not protecting all versions of that file - to make that happen would be difficult and CPU-intensive, because Git does not model a direct link between the different versions of that file.
Beyond that, even if the content of the file never changes, The BFG may remove it from older commits. This is because the BFG actually performs memoization at the level of trees and commits, but not at the level of blobs - and the protection operates at that level too. So you're not protecting files (like y.txt) when you protect a commit - you're protecting folders. If
a folder changes in any way (ie a different file changes), that is enough to remove the protection from earlier versions of that folder.
I hope that explanation makes sense. It's slightly more nuanced than I wanted to put onto the main documentation page.
So, to summarise your issue:
This kind of question has come up before - eg in https://github.com/rtyley/bfg-repo-cleaner/issues/49#issuecomment-47591961 and the answer is a little subtle:
y.txt) when you protect a commit - you're protecting folders. If a folder changes in any way (ie a different file changes), that is enough to remove the protection from earlier versions of that folder.I hope that explanation makes sense. It's slightly more nuanced than I wanted to put onto the main documentation page.
Originally posted by @rtyley in https://github.com/rtyley/bfg-repo-cleaner/issues/53#issuecomment-50088997