I wonder how they deal with the "bisect" flow? I use git bisect a lot and can't imagine how it would go with every WiP commit... (my answer: an unusable nightmare). Good luck with that.
Fossil's bisect works better than Git's in my experience, since Fossil's data model permits bidirectional tracing, whereas Git can go backwards in time only. This allows commands like "fossil bisect status" to show where you are in the decision tree, since it has to trace forward in time as well to provide the answer.
Fossil's strong resistance to changing committed history encourages a culture of not committing predictably-broken stuff, at least not to long-lived branches. This seems like an inherently good thing, to me. Every commit to long-lived development branches should pass all tests and should build on every supported platform. Fossil has tools for fixing this after the fact, but test-first development is your first line of defense for avoiding problems here.
If you're doing experimental work, you do it on a branch in Fossil, which unlike in Git is sync'd globally across all repo clones, so you can do things like check out the branch on another machine and test there before merging it down to the parent branch, presumably one of these long-lived development branches. This is useful in cross-platform development, so you catch portability problems.
(Incidentally, this merge point provides most of the benefits of Git's rebase without rewriting history and without losing the record of how you got to that merge point.)
Fossil just got a feature to avoid the need for a branch in that case: "fossil patch", which creates a Fossil repository (a specially-formatted SQLite database) with as little as one proposed commit, then gives you tools for schlepping that to another repo and integrating it temporarily so you can test on another machine before committing anything. These patch files solve all of the problems with "diff -u": preserve commit comments, file additions/deletions/renames, branches/tags, and so forth.
Fossil's shortest-path bisect algorithm can sometimes cause it to go down unstable branches, but there are ways to redirect it back to the stable branch or to skip broken commits.
Fossil is quite the antithesis of unusable and nightmarish in my experience.
Agreed. I'm entirely not following how a commit stream that may contain entirely broken commits aids in bisecting to find a specific flaw. Those would just be noise, at best. Even if you're just manually testing each commit, you do need it to build and run.
Does everyone test if their commits don't break the build? I doubt that, e.g. if you want to commit before going home, there isn't always time to test and more importantly until you push to master/target branch there is no need for it besides bisection, which I'm not sure if is common.
Depends on your workflow of course. Having all commits on master always pass tests (and thus requiring to rebase the merged branches so their individual commits pass) has advantages (such as this easy bisect).
You would still be able to commit and push to your feature branch without breaking the CI. I guess it would be possible to enforce the rules on feature branches but that would be counter productive IMO.
OK, but if you commit on feature branches then those commits will land also on master (squashing is not something popular and makes frequent commits pointless).
Frequent commits (without making sure they pass tests) allow better git blame/annotate (figuring out why given line of code was added, and having a general comment "introduce feature ABC" is not helpful, but having a message "add field to to something" is).
You can't make detailed commit messages if you have large changes.
But yeah, everything depends on the workflow one commits to.
When I worked with git I squashed/reordered my feature branch to make it pass tests on every commit before merging it with the master. This is usually not very hard and you can still do small commits. You can even split new tests into a separate commit.
Honestly I don’t really see why would you want to change code that breaks tests without updating them in the same commit. Updates in tests give strong signal to the PR reviewer to see that an API has changed. When fixing bugs it’s also nice to be able to reproduce it with a test case first, then fix it.
The problem is that bisect depends on being able to determine whether the commit you land on has the newly found bug or not. That almost certainly depends on it at least building, so that you can run it and check. If you can't do that then you can't determine if the bug exists on that commit, and you can't bisect effectively.
Fossil's strong resistance to changing committed history encourages a culture of not committing predictably-broken stuff, at least not to long-lived branches. This seems like an inherently good thing, to me. Every commit to long-lived development branches should pass all tests and should build on every supported platform. Fossil has tools for fixing this after the fact, but test-first development is your first line of defense for avoiding problems here.
If you're doing experimental work, you do it on a branch in Fossil, which unlike in Git is sync'd globally across all repo clones, so you can do things like check out the branch on another machine and test there before merging it down to the parent branch, presumably one of these long-lived development branches. This is useful in cross-platform development, so you catch portability problems.
(Incidentally, this merge point provides most of the benefits of Git's rebase without rewriting history and without losing the record of how you got to that merge point.)
Fossil just got a feature to avoid the need for a branch in that case: "fossil patch", which creates a Fossil repository (a specially-formatted SQLite database) with as little as one proposed commit, then gives you tools for schlepping that to another repo and integrating it temporarily so you can test on another machine before committing anything. These patch files solve all of the problems with "diff -u": preserve commit comments, file additions/deletions/renames, branches/tags, and so forth.
Fossil's shortest-path bisect algorithm can sometimes cause it to go down unstable branches, but there are ways to redirect it back to the stable branch or to skip broken commits.
Fossil is quite the antithesis of unusable and nightmarish in my experience.