> While you shouldn't be working on multiple things, I and most other people I met, end up doing so Fossil solves that with branches. Merging a branch into the

> While you shouldn't be working on multiple things, I and most other people I met, end up doing so Fossil solves that with branches. Merging a branch into the trunk is equivalent to what Git calls pushing. The difference is that everyone can see your branch, unless you use a private branch, which is more like Git. I've argued the advantages of working on a public branch already, though, so I won't repeat that here. That reminds me of another big difference between Fossil and Git. With Git, the checkout tree and the local repo clone are tied up in a single directory tree. The normal way to switch branches is to check all of your local changes in, then switch the current working directory over to the other branch. While you can do that in Fossil, too, because the repository is a separate file, when working with long-lived branches, it is easier to have separate checkout trees, one for each such branch. The advantage is that switching branches doesn't change all the timestamps for changed files, invalidating build artifacts and such. To get the same effect with Git, you have to clone the whole repo for each long-lived branch, which complicates things greatly, and wastes a bunch of disk space. > It's not protectionist or perfectionist to keep non-working code out of the main branch So check it in on a feature branch or a private branch. Once the new feature in the branch functions as intended, merge it into the trunk. > why should everyone else have a non-working version of it for the duration of the rewrite? If it's a public branch, their Fossil pulls will indeed give them a copy of your branch, but they will only be able to see your checkin comments in the Timeline view, by default. That tells your team members what you're working on, which, as I've already argued, is a good thing. If they have concerns about your direction, they can switch to your branch (a la Git) or check it out into a separate working tree. Or, they can just ignore it, and let you get about your business. > often you _can't_ consult them I already stated it above: if you're working on a project where you're not really collaborating with people, and where haring off in your own direction is a normal thing, then Git may well be the correct tool for you. Fossil is for coherent projects, where people are expected to work together. The SQLite project, which Fossil was created for, is an example of this: to join the project, you have to first impress someone enough to get a commit bit, then you sign the contributor agreement. You are expected to participate on the developer mailing list once accepted. Fossil is also good for traditional corporate development, where those with commit bits are your coworkers. > I don't see how private branches encourage of facilitate [rewriting other people's code] Git's normal working model is that your checkins are local first, then only optionally pushed back to the repo you cloned from. I'd bet a whole lot of the forks on GitHub will no longer integrate back into the parent project. You can see this in the language they use: forking. This is not necessarily a bad thing. If you need federated development, Git's your tool. But if instead you're after collaborators, contributors, and coworkers, you don't want forking the repo to be the normal first step. > I'm not seeing why your model is inherently any better than make sure tests pass after a merge. The "guy in the room" spends days or weeks working on code without showing anyone what he's up to. Then there is a big-bang merge event, which may or may not succeed, and may wreck his coworkers plans. If you ignore private branches in Fossil, you end up either working on the trunk, where your coworkers will immediately see your changes, or working on a public branch, where they're likely to at least see your checkin comments, and can look at your changes if they become concerned about your direction. If you're working on a public branch, you still have the merge event, but your coworkers can't really say they're surprised when it happens, since they've been seeing your work as it progresses. On the Fossil mailing list, you frequently see one of the core developers claiming to have finished a feature, asking for comment on their feature branch before merging it. The "guy in the room" doesn't ask for comment; he just drops his magnum opus into the trunk and says "deal with it." > Fossil does not, your build and project environments do. You've misunderstood my point. 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.) This means that if someone else changes the branch in a way that breaks the tests or whatever, Fossil strongly encourages you to pull those changes into your checkout where you can deal with it. Git, by contrast, lets individual developers do all their checkins on a private branch, then push the whole thing to the repo they cloned from. GitHub embodies this in the pull request. There is no equivalent in Fossil, because Fossil isn't intended for federated development; it's for collaborative development. > Nothing is stopping me but convention and what I decide to do. 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.