> Windows Vista...components were being developed in private branches.

The claim isn't that Microsoft developers on the Vista project used Git and private branches. The claim is that private branches are another form of siloing which leads to the same sorts of communication problems. They're a way to purposefully hoard code so your fellow developers can't see it. It is exactly what McCarthy was warning about in his "beware a guy in a room" comment; and McCarthy was at Microsoft when he wrote the book cited.

> I can't tell if the book specifically says private branches have anything to do with ego or not.

Weinberger wrote his seminal book in 1972, so probably not. :)

Human psychology hasn't notably changed since 1972. It doesn't matter if you're developing with punched cards or with worldwide Kubernetes clusters, humans are humans.

> Single-person development happens in branches only that single person cares about, so whether the branches are private or public makes no difference to that person

If you're doing single-person development, then the concerns over siloed development don't apply at all.

This section of the document is talking about communication among developers on the same project. If there is no communication on your project, its points are irrelevant, not wrong.

>4.0...So test each commit then.

You're missing the point. If Fossil offered Git-style rebase, the commit would be pushed up to the remote repo you cloned from before you could possibly test it, because of its autosync feature.

The autosync feature and the practice of leaving it enabled as much as possible is justified here: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

> `git rebase --ignore-date` will reset the commit date

How often do you suppose that's done in practice?

The point in the article you're rebutting is that Fossil doesn't make you do that at all, because it doesn't create timewarps or require after-the-fact date rewrites to avoid them.

> I'm not sure what (4) is referring to by "routine display"

It refers to the "fossil amend COMMITID --hide" feature. Affected branches no longer show up in the timeline, in the default branch list, etc., but no info is destroyed. It's just a tag telling the web UI and CLI not to show that branch by default.

> I don't need to go through half-commits that got reverted afterwards.

You're assuming 20/20 foresight. The very nature of software bugs is that you don't know you're committing them at the time, so how can you prospectively know which elements of a commit are good and which bad? You can mitigate it through testing, code review, etc., but Bugs Happen. There are whole companies dedicated to that fact.

The very point of bisect is, "Given this pile of commits between points GOOD and BAD, which one caused the symptom I'm seeing now?" If you knew the answer to that, and thus were able to make the in-advance judgement you suggest, you wouldn't need to do the bisect, because you wouldn't have committed the bug in the first place.

> this directly contradicts 4.0 unless we are to assume that only merge commits get tested

Only if you assume you have 100% test coverage, both in terms of lines of code and functionality. If you are in such a happy position, and you always run your tests before committing, then yes, it is impossible to commit a bug to the repo.

I wanna see that repo, the one without bugs because it has 100% functional-test coverage.

Even SQLite hasn't got that, evidenced by the fact that its test suite continues to change, even for historical features.

> If I have to squash two commits in my WIP branch I absolutely want to be able to.

You're toggling between "have to" and "want to".

And again, you're assuming 20/20 foresight, that you will never want to come back and tease those commits apart again.

The merge point is the proper place to logically "squash" things, not within the WIP branch.