[wyoung2]

That part of the article isn't talking about WIP branches, experimental branches, etc. My personal Fossil development philosophy is that you can go wild on those. The article's point applies primarily to long-lived development branches, things like what Git now calls "main", which Fossil calls "trunk". Commits to such branches should always build and pass all tests on all supported platforms.

[temac]

Serious projects with a non-trivial amont of people working on them don't rewrite the git history of "real" branches anyway, except maybe on very rare and targetted occasions (which are more to be understood as: let build a new repository with some resamblance to the old one)

I could see projects with a very low number of devs AND users doing that, but even then they should probably not.

Does that mean that all the tooling to cherry pick / rebase / filter / import-export patch series, shall disappear? Certainly not, because there are things that are _not_ main branches. An alternative could be to develop with completely different tooling, but I'm not sure what would be the point.

So it actually looks like Fossil and Git basic good practices are quite similar, and I really don't see the point in pretending that the lack of support by fossils for some operations is an advantage. E.g. part of preparation of a good patch series suitable for a proper review often involves reordering, mixing and splitting commits. It is easier to do if the tooling does not actually try to prevent you from doing it because of some kind of misapplied dogma...

[richie_adler]

Can you please point to the part of the document where somebody is forcing you to use a tool you don't like?

[temac]

That's not what I meant.

I simply disagree with the position that it is better to not have the tools integrated for "history" rewriting in a version control system, esp. when that position is presented quite aggressively against VCS that have those tools, when such tools are in practice overwhelmingly used correctly (and where they should be abused overwhelmingly for it to become something to get ride of despite the existence of valid use cases, leaving a huge margins between the real and the straw man situation). I actually would not even call that part of (most of) the tooling "history rewriting" but more "patch preparation" tools, because that's what they are used for. In my books, conflating with the flow WIP changes with "real" commits has little value, but I see value in using some of the same tooling to handle the two. I also typically do not want to long-term track false starts and the WIP history, but if I wanted to I could with git, and that would even be trivial to do.

It is fine for a VCS to not propose anything for history rewriting, it is not fine to criticize others by employing a discourse making it look the mere existence of such possibilities is a mistake that is often abused, when it is not.

BUT if some people found some value in that and good alternative workflows for their projects, with Fossil, good for them. It is just that for now, on my side, I'm (highly) unconvinced. And I'm not forced to use that. And I don't. And if limitations are to be considered a main advantage, I could as well put a few aliases and conf in place to forbid be from invoking some git commands anyway, and continue to happily use the rest...