3 ms·
> I amend commits in Git quite often before pushing. Fossil supports amending checkins at any time after committing, as often as you like - change the checkin
by sgbeal 4y ago
> I amend commits in Git quite often before pushing.
Fossil supports amending checkins at any time after committing, as often as you like - change the checkin commit, re-attribute to a different user, change the timestamp, or similar. What it doesn't support is _modifying_ them.
> And then there's this: what if I accidentally commit a private key or database?
Then you "shun" (to use fossil's term) that artifact. Fossil isn't 100% merciless when it comes to removing content, it just makes doing so a 4th-class sub-citizen of a feature and recommends against doing so in every case except for the one of content which should never have been checked in. Removing content inherently punches holes in the project history, so it's not something we (in the fossil project) recommend doing unless it's absolutely necessary for reasons of security or legality.
- colejohnson66 4y agoWhy do you mean "modify"? As in rewriting history (commits before HEAD)?
- sgbeal 4y ago> Why do you mean "modify"? As in rewriting history (commits before HEAD)? Fossil flat-out does not support, with the exception of "shunning" (forcibly removing content), the modification of any history. It supports the "amending" of any history, however. For example, you can "change" the timestamp of a commit retroactively. It doesn't change the timestamp on the actual checkin (as that's cryptographically baked into the commit), but it changes how the checkin is displayed to the user in fossil's "timeline" view. Fossil also, however, makes it easy to see, in the details for that checkin, that the timestamp was modified later (and who did it, as well as when they did it).