|
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... |