| (Holy shit I didn't realize how long this had gotten.) I read that page. It's their opinion and I disagree with it. To be clear of where I'm coming from, I've never used fossil, and I've used git regularly for about 10 years. I only use git from the commandline except that I often use `gitk` to read a branch's commit history or inspect diffs, and I use `kdiff3` for interactive merging when there are conflicts. I actively disable git "integrations" in editors and IDEs. --- >1.0 Whether other people struggle with rebase or not does not affect me, because I have no problems using it. (This logic also extends to people who complain the entire git CLI is hard to use.) Now, this might sound like the seasoned C programmer saying "Other people accidentally write UB but I don't, so C is perfectly fine." but there is a difference. UB with C is problematic because it's hard to know it happened, which is why we know the seasoned C programmer might have unknowingly written UB after all. This is not the case with `git rebase` though. Either you do it correctly or you don't, and I can confidently say I do it correctly. >2.1 This is specifically talking about rebases that move commits onto new parents. Rebase does much more than that. For this particular use case, I agree that some projects even when using git prefer to have merge commits instead of rebased commits, and that's fine. But for projects that do want a linear series of commits, it's good to have the choice. Rebased commits also make it easier to revert just a single commit instead of the whole merge (though of course it's not impossible to revert a single commit of a merged branch either). >2.2 This whole section is a non-sequitur because indeed the correct pre-rebase diff would indeed be diff(C2, C5) even in the git case. But if you're planning to rebase the code in order to merge it, you need to rebase the code to know what the diff will be. >3.0 The Windows Vista citation starts off with the (correct) result that lack of communication between engineers of disparate components leads to bugs, but then associates it to mean that these disparate components were being developed in private branches. The cited paper does not talk about branches at all. Indeed, bugs happening because of private branches was not the case then, and is not the case now. The reason those bugs happen is because the engineers of a particular component only work with code of their component. The "egoless" citation is from a book, so I can't tell if the book specifically says private branches have anything to do with ego or not. At any rate, this section is fundamentally confused. Making branches public doesn't mean you can't rebase them. If I work on an OSS github project, I would certainly make my WIP code branch public. That doesn't mean I don't want to rebase it right before I send a PR to clean the cruft up. I think the article author may have read the git advice about not rebasing public branches and thought it meant all non-private branches. It actually means branches other people would want to pull from you and who are not expecting it to be rebased. 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 wanting to be able to rebase them. If a group of people are collaborating and they agree that rebases are going to happen, nothing is wrong with letting them do that. The only problem is with rebasing public branches that people pull from and which those people do not expect to be rebased, like a public repo's `master`. >4.0 So test each commit then. git doesn't makes it impossible to do that or anything. If anything, ensuring tests pass on each intermediate commit makes `bisect`ing easier in the future. Also, only using merges means the only tested commit is the merge commit, so you lose the ability to check which commit in the merged branch caused the problem. See also 7.0 >5.0 `git rebase --ignore-date` will reset the commit date of each rebased commit to the current time. >6.0 It is correct that commit messages are the only way to associate some of the metadata that Fossil lets you manipulate separately. So (2) and (3) do benefit from Fossil's approach. (1) and especially (5) happens rarely enough in my experience that it isn't enough justification. I'm not sure what (4) is referring to by "routine display", but in general the only branches things like `gitk` will show you are the ones you ask for. >7.0 It also throws away non-valuable garbage. When I'm bisecting a bug, or running a `blame` to figure out what commit added a particular line, I don't need to go through half-commits that got reverted afterwards. False starts and incorrect approaches can be documented in the commit message or in the code comments. Also this directly contradicts 4.0 unless we are to assume that only merge commits get tested, and that the user running `blame` does not go deeper than the merge that introduced the line, which has the problem I mentioned in 4.0 >7.1 This section is just a longer reiteration of 7.0, so it has the same rebuttal. >7.2 This has switched to specifically talking about squash rebases, which is not necessarily the only kind of rebase (and is also not the kind of rebase that the diagram in 2.2 was talking about). I also dislike squashed rebases when merging pulls. But if I have to squash two commits in my WIP branch I absolutely want to be able to. >7.3 If the checkins are being rebased and are going to be merged without squashing, then each commit has to stand on its own by definition, so of course they should all have individual justifications. >7.4, 7.5 These are the same as 7.2 and 8.0 below. >8.0 This appears to be saying that fossil's cherry-pick is not just a wrapper around rebase like git's is. So I agree that (1) and (4) are benefits due to Fossil's approach. (2) is exactly the same as 4.0 I don't understand what (3) is trying to say. |
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.