4 ms·

> Like Git, Fossil has an amend command for modifying prior commits, but unlike in Git, this works not by replacing data in the repository, but by adding a corr

by Svip 5y ago

> Like Git, Fossil has an amend command for modifying prior commits, but unlike in Git, this works not by replacing data in the repository, but by adding a correction record to the repository that affects how later Fossil operations present the corrected data. I may be misreading this, but what if I accidentally commit (not push) a piece of sensitive data (say a private key), but notice before I commit. In Git, I would simply remove it, and amend, and it is now gone from the Git history. It sounds like with Fossil, it would remain in the history, or am I misunderstanding something? There are times where being able to rewrite the history is critical.

badsectoracula 5y ago
In Fossil it will remain in your local repository but you can put the hash for the data you accidentally committed in a "blacklist" so that it wont be pushed/pulled. I think you can also rebuild the local repository to purge any data, though i'm not 100% sure about that. (though you can certainly make a local clone of it which wont clone the blacklisted data, but you may need to manually copy/configure some stuff that aren't cloned)
ashtonkem 5y ago
Careful, amending doesn’t actually remove the bad commit, but it rather creates a new one and changes the appropriate branch pointer towards it. The old commit is still there, browsable if you know what you’re doing. This is fine if you’re doing it locally only, but incredibly misleading if you’ve already pushed the bad commit to a remote repository. It’s possible to remove sensitive data from Git, but it requires commands rarely used in a day to day workflow. It’s better to assume that any committed credential is burned and re-issue them.
richie_adler 5y ago
> what if I accidentally commit (not push) a piece of sensitive data (say a private key), but notice before I commit Fossil has autosync by default, so the commit has probably reached another instance anyway. But it has a provision exactly for those cases, the shunning mechanism. https://fossil-scm.org/home/doc/trunk/www/shunning.wiki https://fossil-scm.org/home/doc/trunk/www/shunning.wiki

by Svip 5y ago

badsectoracula 5y ago

In Fossil it will remain in your local repository but you can put the hash for the data you accidentally committed in a "blacklist" so that it wont be pushed/pulled. I think you can also rebuild the local repository to purge any data, though i'm not 100% sure about that. (though you can certainly make a local clone of it which wont clone the blacklisted data, but you may need to manually copy/configure some stuff that aren't cloned)

ashtonkem 5y ago

Careful, amending doesn’t actually remove the bad commit, but it rather creates a new one and changes the appropriate branch pointer towards it. The old commit is still there, browsable if you know what you’re doing. This is fine if you’re doing it locally only, but incredibly misleading if you’ve already pushed the bad commit to a remote repository. It’s possible to remove sensitive data from Git, but it requires commands rarely used in a day to day workflow. It’s better to assume that any committed credential is burned and re-issue them.

richie_adler 5y ago

> what if I accidentally commit (not push) a piece of sensitive data (say a private key), but notice before I commit Fossil has autosync by default, so the commit has probably reached another instance anyway. But it has a provision exactly for those cases, the shunning mechanism. https://fossil-scm.org/home/doc/trunk/www/shunning.wiki https://fossil-scm.org/home/doc/trunk/www/shunning.wiki