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

This is such a painfully armchair-psychologist point of view I don't even want to attempt to disprove it.

But consider this: if committing in fossil makes your code immediately visibile to the world, and if we are to assume the people using git want to hide their "imperfect" code in those evil bad private branches (even though, as I wrote in my comment, the whole private-vs-public distinction is irrelevant), one must assume those same people using fossil will also want to hide their "imperfect" code too. Doesn't that mean people using fossil will just commit less frequently?

---

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

Please read the next sentence I wrote right after where you stopped quoting.

---

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

Okay, so it's a fossil-specific problem with a hypothetical fossil-rebase implementation, not a problem with git-rebase, unlike the rest of the page that's pointing out problems with git-rebase. I'm sorry for "missing the point".

---

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

If the repo is on Github and the PR is being merged through its web interface, that is one of the default merge options the repo admins can set.

In other cases, the person doing the merge can remember to use it.

Many options have defaults that can be configured, and this isn't one of them. So either nobody has implemented it yet, or the occurrences of time travel in a linear history hasn't bothered enough people yet. I suspect it's the latter.

---

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

Okay, so it's not related to rebase then, in git or otherwise.

---

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

I don't think you understood the situation I wrote about. I'm talking about using blame or bisect to go through the history of code that has already been committed, trying to find the source of a line of code or a bug.

See https://news.ycombinator.com/item?id=24643869 for an example.

---

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

There is no such assumption in what I wrote.

---

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

The sentence I wrote is both grammatically and semantically correct. It would not be correct to use two "have to"s, nor would it be correct to use two "want to"s.

---

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

Listen, if I have a commit:

bar the foo

+ foo.bar()

and then another:

derp

- foo.bar()
+ foo.bar();

... then I'm very confident I want to squash them together, thanks. I'm also very confident that when I send a pull request, I want the commit to read

Invoke bar on the foo object before it's baz'd, otherwise foo is in an undefined state.

Fixes #3

+ foo.bar();