[wyoung2]

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

[Arnavion]

>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();

[wyoung2]

> one must assume those same people using fossil will also want to hide their "imperfect" code too

One must not, because if one did, one would be wrong. :)

Go read Weinberger. It's $10 on Kindle right now.

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

First, don't assume that because I didn't quote your posting in full that I didn't read it in full. HN is a threaded messaging system: we don't need to fully quote everything just to maintain the flow of the conversation. The history is right there to see on the page.

Second, how does "If a group of people are collaborating and they agree that rebases are going to happen, nothing is wrong with letting them do that," argue against the article in question? That's just a blind assertion, not logical argumentation.

> not a problem with git-rebase,

Sure it is: if rebase commits a breaking change to the blockchain immediately because you weren't able to test it, you have two options: 1. Commit a fix, pushing the broken commit later, potentially breaking bisect and such. 2. Do more rebase squashing and such to fix it in place before pushing it.

Argument 2 is "We need rebase because we used rebase." :)

Fossil's alternative is to not commit anything to the blockchain automatically. If Fossil did have rebase, it would make the changes in the checkout tree only, and you'd have to commit it separately.

The argument is not "Fossil can't have rebase because Git's version is badly considered," it's "Fossil's developers don't want rebase and Git's version is badly considered anyway." Fossil could avoid the design error, but that doesn't make rebase a good idea.

> If the repo is on Github and the PR is being merged through its web interface

...then you're using proprietary software with tremendous lock-in, but okay, if you're willing...

> the merge can remember to use it.

You're really going to insist on that? Commands by the foot, instead of a sensible default?

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

It's an example. The argument we've received multiple times from Git fans is that developers need rebase to make the timeline "clean", but Fossil shows that you don't have to modify history to do that. You just need sufficiently powerful tools that let you preserve history while changing its presentation to the user to suit various needs.

Git's porcelain is showing here.

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

So you've committed without compiling first, much less running the tests, and your solution is "I need rebase?" No, my friend, you need to compile and run the tests before committing!

Maybe you want a better example?

[Arnavion]

>Go read Weinberger. It's $10 on Kindle right now.

No, I think I'll pass. If this conversation is anything to go by, it's not going to be worth my time or my money to read it.

---

>First, don't assume that because I didn't quote your posting in full that I didn't read it in full.

I charitably assumed you didn't read it, as opposed to assuming you read it and ignored it, because it was written specifically to counter the very point you made.

---

>Second, how does "If a group of people are collaborating and they agree that rebases are going to happen, nothing is wrong with letting them do that," argue against the article in question? That's just a blind assertion, not logical argumentation.

It's not a logical argumentation, just like the article in question isn't one. However it is based on real life observation, so it can't really be called "blind".

---

>> not a problem with git-rebase,

>Sure it is: if rebase commits a breaking change to the blockchain immediately

There is no "blockchain" in git. Furthermore, you said:

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

Therefore this whole situation of "intermediate commits weren't tested" only happens because fossil pushed the commits remotely "before you could possibly test it". This would not be a problem with git because you can run tests on each individual commit before you push them to the remote repo just fine. It also doesn't have anything to do with git-rebase specifically; you can run tests on individual commits regardless of whether they were created by rebasing or not, again before pushing them to the remote repo. Also, the remote repo can enforce that tests must pass on each individual commit, so even if the committer doesn't do it, the server can.

---

>You're really going to insist on that? Commands by the foot, instead of a sensible default?

Again, as I wrote:

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

---

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

>It's an example. The argument we've received multiple times from Git fans is that developers need rebase to make the timeline "clean", but Fossil shows that you don't have to modify history to do that. You just need sufficiently powerful tools that let you preserve history while changing its presentation to the user to suit various needs.

The point in the article was:

>>>4. Cause mistaken or unused branches to be hidden from routine display

Given that it's talking about fossil's "routine display" as opposed to git's, and given that rebasing has nothing to do with hiding "mistaken or unused" branches as it calls them, yes the point is indeed not related to rebase in any way.

---

>So you've committed without compiling first, much less running the tests, and your solution is "I need rebase?" No, my friend, you need to compile and run the tests before committing!

>Maybe you want a better example?

No, I don't think I need a better example, nor do I need to continue this conversation. It's clear to me that fossil requires me to do things in a very different way than I want to. No committing unless it's the final perfect code, because it's the only shot I have at the final thing.

- If I messed up some formatting, I won't be able to fix it in this commit.

- If I feel like some comment could be clearer, or some variable could be named better, I've lost my chance.

- If I added a test that works for me but then I realize it won't work in X situation, I've lost my chance.

- If I'm in the middle of implementing something and just want a nice checkpoint I can `git reset --hard` to while I try something speculative, I can't do that without committing to it forever.

- If I go ahead and make these half-commits anyway, my branch's history is full of incomplete commits. The repo can't possibly enforce running tests on every commit, because everyone will have such incomplete commits in their branches, so at best the repo can only enforce running tests on merge commits. Anyone using `blame` or `bisect` in the future is going to accidentally land on this commit, so they too have to get used to not digging deeper than merge commits. If there's a bug that's tracked to a particular merge commit, the easiest thing to do is just revert the whole merge, rather than try to identify which commit(s) inside the merged branch needs to be reverted.

I'm sure it works out well for the people who use fossil. It's not for me.

[philmaker222]

Re: >>Go read Weinberger. It's $10 on Kindle right now.

And the response >No, I think I'll pass. If this conversation is anything >to go by, it's not going to be worth my time or my money to read it.

Comrade, can I perhaps humbly submit that this is a very good piece of advice for all of us. The General Systems Thinking one is great as well.

1971. The Psychology of Computer Programming. Silver Anniversary Edition (1998). ISBN 0-932633-42-0 1975. An Introduction to General Systems Thinking. Silver Anniversary Edition (2001). ISBN 0-932633-4