|
|
|
|
|
|
by GuB-42
998 days ago
|
|
|
It is a problem in all decentralized systems. Once you publish something, there is no going back. Anyone of your peers can decide to leave with your sensitive data. That's also what make them so resistant to data loss. Now if you know everyone who has a copy of your repository, you can have them run a bunch of sqlite commands / low level git commands to make sure that the commit is gone. If you didn't publish anything, as someone else said, your best bet is to make an entirely new clone, transfer the work you did on the original, omitting the sensitive data, then nuke the original. The difference seems to be that commits are serious business on fossil, and they encourage you to test before you commit. While on git, commits are more trivial, pushing is where things become serious. |
|
|
Or you can just rebase to edit the commits and remove the secret file. If you're really paranoid you can run `git gc` vto ensure the object file is cleaned up also. If you're super paranoid, then you can do:
git hash-object secretpassword.txt
And check that hash isn't an object in the `.git/objects` directory.