Comment by nomel
3 months ago
> even though it is, of course, entirely possible
I take the more realistic perspective: until git makes it impossible to commit something that shouldn't have been, like a secret, then deleting a file from history is a fundamental requirement of git.
Even if you purge the history, the secret is compromised and you should stop using it. It's moot whether or not you're able to remove it from history.
That's, for secrets. Secrets aren't the only thing one might want to remove retroactively.
The designers of git clearly disagreed, as you can guess from its design, so it's not surprising it might feel like a bit of an uphill struggle (and will probably remain so). There are other tools available.
> The designers of git clearly disagreed
filter-branch has been around since, at least, 1.8. It exists to rewrite history, this specific use case (as the official documentation details) included. An open source project admitting that a solution is better than their own does not mean the developers "disagree" with it, especially when the functionality has already been part of the developers tool for over a decade.
But if they didn't disagree, they'd have designed a system that made removing things from remote history easy, rather than a complete pain in the ass that's basically impossible to make work usefully anyway. The whole thing runs largely based on commit hashes, and when you change history, all the commit hashes change, and... good luck. This behaviour has some useful properties but it's quite often not what you want. And that isn't how this sort of system inevitably has to work! - but git does anyway, and always has done.
(By comparison, if you want to delete something from the Perforce history, there is a command for that. You can remove individual revisions, leaving gaps in the history, or the whole thing.)
1 reply →