If Fossil is so against deleting commits, what do you do if you've accidentally committed sensitive information that cannot live in any form in the repo?
Fossil provides a mechanism called "shunning" for removing content from a repository.
Every Fossil repository maintains a list of the hash names of "shunned" artifacts. Fossil will refuse to push or pull any shunned artifact. Furthermore, all shunned artifacts (but not the shunning list itself) are removed from the repository whenever the repository is reconstructed using the "rebuild" command.
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.
That's a good point. Delete the repo and start over I suppose? W/ git wouldn't it possible to find and restore that info anyway? Guess it becomes what do you care about most at that point.
blacksqr|2 years ago
Every Fossil repository maintains a list of the hash names of "shunned" artifacts. Fossil will refuse to push or pull any shunned artifact. Furthermore, all shunned artifacts (but not the shunning list itself) are removed from the repository whenever the repository is reconstructed using the "rebuild" command.
https://fossil-scm.org/home/doc/trunk/www/shunning.wiki
GuB-42|2 years ago
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.
revertmean|2 years ago
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.
maccard|2 years ago
mkl|2 years ago
> FURTHER WARNING: This command is a work-in-progress and may yet contain bugs.
mdgrech23|2 years ago