How about temporary commits locally, that then get squashed to ensure each build cleanly? Or secrets that shouldn’t have been committed?
Maybe it what an ironical question ^^
Maybe it what an ironical question ^^
And I don't know why (forces you to review and cofirm?), but I had never commited unwanted stuff with fossil. But I had with git, probably by using the -am flag without realising a whole new dir is now in the scope.
We disagree here, thus we prefer different tools. Nothing elitist here.
I have seen git people throwing away repos and start again just to hide mistakes/pivoting and look "pro" and "right from the start". Or worse, I have seen people botching repos to others rewritting history just to make them look clean. I embrace mistakes, and sometimes they become useful later to replay train of thoughs.
In teams, only the history of what is committed to shared repo is important.
There are cases where you really do want an append-only leger, where tampering with history is malicious. -- But, generally, it's preferable to be presented with something tidy.
From some other comment in this thread, I get the impression it's possible to re-present a set of changes in a clean/tidy way? That seems a better way of putting it. "You can still have a clean view into a set of changes while preserving an accurate history of what changed".
What's hard to understand is why you'd be against the idea of tidy communication/presentation of changes in the first place.
...which is a very big advantage, big enough that it outweighs the disadvantages in my opinion.
With git, this kind of experiment would be hidden with a "reset hard", and probably will happen again when people forgets, someone says "didn't we try that a year ago?" but we have no records.
This is very helpful in small private teams, not so much in biggest teams (kernel), pass-by PR environments (github), or public CV-oriented repos (no mistakes allowed there, only pretty linear timelines).
In the most common git setups, you never force-push to master - so a coworker can't rewrite history of master branch. Forges have protection rules, but even if your hosting does not, then the "git pull" will throw a ton of errors after history rewrites. So both fossil and git are similar in that regards.
On the other hand, unpushed branches can be rewritten any time in git.. but this applies to fossil as well. If you have not pushed your fossil changes, it's just a file on disk - you can delete it without pushing and no one will ever know you had intermediate version. Or work in "git" and only export to fossil (or svn or cvs or whatever) once things work.