4 ms·

I'm torn on that "feature." On one hand, I think it's a neat idea, but on the other, I amend commits in Git quite often before pushing. It would take a mindset

I'm torn on that "feature." On one hand, I think it's a neat idea, but on the other, I amend commits in Git quite often before pushing. It would take a mindset change to switch. And then there's this: what if I accidentally commit a private key or database? Sure, I shouldn't be f-ing up, but we all know it happens sometimes. In Git, I can revert/reset back to the commit prior.

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 ago
  Why 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).
Too 4y ago
Even in git, amending doesn’t rewrite the actual commit though. It creates a new one. You can find the old in your reflog. Think about it, the commit hash is based on the contents, so it must be changed on any content changes. It’s only after pushing that history is written in stone. So you can say git never removes anything either. The biggest issues with data loss in git is before you have done a commit. There, many actions can nuke your changes because you mixed up two flags, trying to rebase before commiting, etc. As long as you have a commit though, the reflog will save you from failed rebases.

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 ago
Why 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).

Too 4y ago

Even in git, amending doesn’t rewrite the actual commit though. It creates a new one. You can find the old in your reflog. Think about it, the commit hash is based on the contents, so it must be changed on any content changes. It’s only after pushing that history is written in stone. So you can say git never removes anything either. The biggest issues with data loss in git is before you have done a commit. There, many actions can nuke your changes because you mixed up two flags, trying to rebase before commiting, etc. As long as you have a commit though, the reflog will save you from failed rebases.