> Fossil solves that with branches. Merging a branch into the trunk is equivalent to what Git calls pushing.
git does the same thing, though sometimes you're working on two related things, but want to make 2 commits.
> Git's normal working model is that your checkins are local first, then only optionally pushed back to the repo you cloned from.
Because I may not own or be associated with the original repository? Are you saying I shouldn't work on code simply because I can't contact the original author?
> The "guy in the room" doesn't ask for comment; he just drops his magnum opus into the trunk and says "deal with it."
But again, if i'm working on something that necessitates breaking something while it's being fixed, you're saying to use a private branch, so what's the difference?
> Because Fossil defaults to "autosync on", you can't check in a change on a branch that has upstream changes. Fossil simply won't allow it. (There's a "force" option, but it creates a special kind of branch called a fork, which has to be resolved at some point.)
Git has the same ability to prevent forced pushes. I'm still not seeing your point. But also, none of this actually solves the issue that everything you're talking about are environmental and not inherent in the scm, i.e. testing.
> This is why we have social mores and community standards of behavior. It is a good thing if the tools we use support those desirable behaviors.
The tools shouldn't stand in your way when you want to make a coherent idea a single idea instead of multiple little, sometimes conflicting ideas.
It seems to come down to if you believe you own your code and everyone should be "allowed" to work on your code, or if you believe that anyone should be able to work on code. (centralized vs federated).