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?