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