6 ms·

This is obviously written by someone who's never done any sort of review-based workflow. Trying to review the "what you did" with all the random false starts,

• yxhuvud 5y ago
  I wouldn't mind if someone that understood this was involved in the PR review flow development of Github. Because that is clearly not the case.
• wojciechpolak 5y ago
  I wonder how they deal with the "bisect" flow? I use git bisect a lot and can't imagine how it would go with every WiP commit... (my answer: an unusable nightmare). Good luck with that.
  • krzyk 5y ago
    Why? It would be better, I frequently commit in. This way it is even easier to find the offending commit, because changes are smaller (yes, sometimes not working at all).
    • wojciechpolak 5y ago
      Because: "Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors..."
      • mpweiher 5y ago
        Logical errors, dead-ends. You don't commit when the tests fail.
        • Cthulhu_ 5y ago
          Shouldn't, and shouldn't be able to (git pre-commit hook), but some people don't have that, some people use git as cmd+s.
    • yoz-y 5y ago
      If tests must pass in every commit then you can just run bisect with the test runner and go grab a coffee.
      • handrous 5y ago
        Agreed. I'm entirely not following how a commit stream that may contain entirely broken commits aids in bisecting to find a specific flaw. Those would just be noise, at best. Even if you're just manually testing each commit, you do need it to build and run.
        • krzyk 5y ago
          git bisect is not something one thinks when commiting code. And there is a difference between entirely broken builds and not-tested ones.
          • yoz-y 5y ago
            > git bisect is not something one thinks when commiting code. depends on the repo structure > And there is a difference between entirely broken builds and not-tested ones. depends on your testing philosophy and process
      • krzyk 5y ago
        Does everyone test if their commits don't break the build? I doubt that, e.g. if you want to commit before going home, there isn't always time to test and more importantly until you push to master/target branch there is no need for it besides bisection, which I'm not sure if is common.
        • yoz-y 5y ago
          Depends on your workflow of course. Having all commits on master always pass tests (and thus requiring to rebase the merged branches so their individual commits pass) has advantages (such as this easy bisect). You would still be able to commit and push to your feature branch without breaking the CI. I guess it would be possible to enforce the rules on feature branches but that would be counter productive IMO.
    • mcintyre1994 5y ago
      The problem is that bisect depends on being able to determine whether the commit you land on has the newly found bug or not. That almost certainly depends on it at least building, so that you can run it and check. If you can't do that then you can't determine if the bug exists on that commit, and you can't bisect effectively.
      • steerablesafe 5y ago
        You can always skip, can't you?
  • wyoung2 5y ago
    Fossil's bisect works better than Git's in my experience, since Fossil's data model permits bidirectional tracing, whereas Git can go backwards in time only. This allows commands like "fossil bisect status" to show where you are in the decision tree, since it has to trace forward in time as well to provide the answer. Fossil's strong resistance to changing committed history encourages a culture of not committing predictably-broken stuff, at least not to long-lived branches. This seems like an inherently good thing, to me. Every commit to long-lived development branches should pass all tests and should build on every supported platform. Fossil has tools for fixing this after the fact, but test-first development is your first line of defense for avoiding problems here. If you're doing experimental work, you do it on a branch in Fossil, which unlike in Git is sync'd globally across all repo clones, so you can do things like check out the branch on another machine and test there before merging it down to the parent branch, presumably one of these long-lived development branches. This is useful in cross-platform development, so you catch portability problems. (Incidentally, this merge point provides most of the benefits of Git's rebase without rewriting history and without losing the record of how you got to that merge point.) Fossil just got a feature to avoid the need for a branch in that case: "fossil patch", which creates a Fossil repository (a specially-formatted SQLite database) with as little as one proposed commit, then gives you tools for schlepping that to another repo and integrating it temporarily so you can test on another machine before committing anything. These patch files solve all of the problems with "diff -u": preserve commit comments, file additions/deletions/renames, branches/tags, and so forth. Fossil's shortest-path bisect algorithm can sometimes cause it to go down unstable branches, but there are ways to redirect it back to the stable branch or to skip broken commits. Fossil is quite the antithesis of unusable and nightmarish in my experience.
    • wojciechpolak 5y ago
      Quite insightful. Thanks for sharing!
• prionassembly 5y ago
  > Trying to review the "what you did" with all the random false starts, bug fixes, and who knows what, would be a nightmare; At some point there was a plugin for Google Docs where you could record the actual typing of a document; supposedly if good writers (even on the order of Spolsky/Graham) did it, we could stand to learn a lot.
• globular-toast 5y ago
  Completely agree. What on earth is the value in knowing that John decided to commit something at 11:24 29 days ago that may or may not have been complete rubbish? The only reason I am aware of for keeping history is bisecting it to track regressions. The "development history" is completely useless for this purpose. What I want is the version history. That's why git is called a version control system.
  • wyoung2 5y ago
    If John's rubbish ended up in the merge down to trunk, then you absolutely do want to know about that individual commit. If you've never received a 500-line patch with a one-line error in it, you haven't been developing collaboratively for very long. Me, I want all 10 commits so I can see from the commit message why the third commit broke the build on platform X, the one clearly tested only on platform Y. I don't want to disentangle the whole mess-o-hackage with a single vague commit comment ("added the foo feature") when faced with such problems. Am I going to want each and every commit for all history? Of course not, but they're cheap to store, and Fossil makes it easy to ignore the ones not immediately in front of you.
    • gwd 5y ago
      > If you've never received a 500-line patch with a one-line error in it, you haven't been developing collaboratively for very long. Which is why after I've finished doing the development of a big change, I want to rewrite the history into a series of logical patches, each exactly the right size for review.
• darthrupert 5y ago
  Every git forge is able to show changes against target branch without anyone needing to rewrite history, though. Reviews can be done against changes, not individual patches.
  • temac 5y ago
    Let me introduce you to the concept of a patch series...
• bachmeier 5y ago
  > This is obviously written by someone who's never done any sort of review-based workflow. I think you meant to say the following: > This is obviously written by someone who's never used my review-based workflow. As is is so often the case in these discussions, there's a conflation of what works best for one person and what works best in general. I very much doubt that the difference in viewpoints is simply ignorance. Edit: I also wish HN had a rule against this type of dismissal: > the only sustainable model for a project of any size Fossil was designed for the development of SQLite. It does not help the conversation at all to have an anonymous commenter dismiss SQLite as a toy project.
  • gwd 5y ago
    > I very much doubt that the difference in viewpoints is simply ignorance. You can usually tell if a difference in viewpoints is ignorance by how the other person talks about the idea they disagree with. If they don't mention any of the perceived advantages (or try to but miss the most obvious ones -- like, say, the ability to do bisection or review changes), there's a good chance that it's out of ignorance. EDIT: It seems I was slightly mixed up; I was referring not to to the text linked story (which just talks about valuing the "messy" history) but to "Rebase considered harmful" [1], which having just re-read, am confirmed in my opinion was written by someone ignorant of what they're arguing against. [1] https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md > It does not help the conversation at all to have an anonymous commenter dismiss SQLite as a toy project. First, I'm not anonymous -- I don't have my full name in my description, but if you wanted to track me down it shouldn't be too hard based on my comment history. Second, I never said SQLite was a toy project; on the contrary, I said it was "AWESOME". What I said was that it was small; and what I meant was that it had a small development team. My understanding is that SQLite doesn't accept external contributions, and that the team developing it is 4 people (or something on that order of magnitude). With only 3 other people, all hand-picked, committing to your tree, you can afford to just look at the total diff of the branch before merging it (and/or presumably have a conversation about what's in the branch). That's simply not going to work if you're reviewing dozens of patches a day from random people on the internet.
• SQLite 5y ago
  > [Fossil is] basically incapable of rewriting your development branch into something more logical... False. All you need to do is start a separate "presentation branch" and cherrypick and/or merge changes from your "development branch" in as necessary to make it logical for review. Not difficult to do. The difference from Git is that in Git you end up discarding the development branch and keeping only the presentation branch, whereas Fossil preserves them both. Fossil does anything Git will do, except for one thing: Fossil does not (easily) sync individual branches. (You can do it, but it is a pain.) Git comes with the idea that individual developers keep their own private branches and only share them after they've been cleaned up. The idea behind Fossil is that everybody shares everything. By analogy: Git is like where everybody has their own office with doors that close, and developers emerge from their own office from time to time to share their work or collaborate. Fossil is more like an open office with no walls or doors. There are advantages and disadvantages to both approaches. I encourage you to use whichever one works best for you. If you like the Git approach, then by all means use Git. I find that the Fossil approach works better on the projects that I manage, but that just me. You do whatever works best for you. Bottom line: Fossil was created to support SQLite development. It does this very, very well. If it never does anything else, it will have been a great success. Any use of Fossil beyond SQLite is just gravy. As it turns out, many other developers have found Fossil useful, too. But perhaps your usage patterns are different and the Fossil model does not work for you. That does not invalidate the fact that it works well for others. All that said, there are many ideas in Fossil that could be copied into Git without changing the Git development model. So even if you don't like Fossil's development model, you should still look at Fossil, so that you can steal ideas (and/or source code) to import into Git and hence make Git better.
  • deleted 5y ago
    [deleted]
  • gwd 5y ago
    > Bottom line: Fossil was created to support SQLite development. It does this very, very well. ...But perhaps your usage patterns are different and the Fossil model does not work for you. That does not invalidate the fact that it works well for others. So first, let me reiterate that SQLite is awesome; you and your team have probably had a larger positive impact on the world per man hour of coding than any software project in the history of the world. You've already given us an amazing self-contained database system; I'm hardly in a position to demand that you write me a version control system as well. Secondly, when I wrote "this could only be written by", I was really mixing up the linked text with another article on your website, "Rebase considered harmful" [1], which is far more opinionated. I'm sorry for getting that slightly mixed up; but only slightly sorry, since the "original designer of Fossil" wrote both; I understand that person to be you. [1] https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md I didn't actually say anything bad about Fossil or that it wasn't a useful system. What I did say was that presenting a change as a series of chunks presented in a logical order, targeted at easy reviewing, is necessary for a large project. I stand beside that assessment. > Git comes with the idea that individual developers keep their own private branches and only share them after they've been cleaned up. The idea behind Fossil is that everybody shares everything. And I can't see how this is remotely sustainable for a large project, or a project hoping for "drive-by" contributions. I understand SQLite to be developed by 4 people or so, who have worked closely together for years; I can see where having every development branch of every developer would be an advantage in your case. And since you don't generally accept external contributions (as I understand it), "drive-by" contributions aren't a consideration. The previous release of my project, which represented only 8 months of development, had changesets from 61 different people; and we frequently get submissions from people who just have a single fix or a single feature they wanted to add, after which we never hear from them again. I can't imagine having every version of every development branch of every person who'd ever contributed to the project (or thought about contributing to the project) in the project log. > By analogy: Git is like where everybody has their own office with doors that close, and developers emerge from their own office from time to time to share their work or collaborate. Fossil is more like an open office with no walls or doors. Git was designed so that thousands of people in different workshops and in different towns could come together in an ad-hoc fashion to share what they'd been doing. Having four people working together in the same keycarded space sounds nice; but having thousands of people in one gigantic gym sounds like pandemonium, and having the doors open so anyone can walk in and start vandalizing the place is unworkable. > False. All you need to do is start a separate "presentation branch" and cherrypick and/or merge changes from your "development branch" in as necessary to make it logical for review. Not difficult to do. And if you need to iterate over that "presentation branch"? Do you make a new "presentation branch" every time you realize some change from patch A would logically go better in patch B or vice versa? Is the final version of the presentation branch automatically linked to the intermediate presentation branches, and the original development branch(es)? In your documentation you seem to be aware that Fossil will "nudge" developers in certain directions -- including "nudging" people to delay checking in changes (e.g., before proper testing). Don't you think having all these previous versions dangling around will "nudge" developers into doing fewer iterations of their "presentation branch", resulting in a branch which is more difficult to review and/or do archaeology on? Don't you think the delaying of check-in, in particular with the knowledge that what you've done will be seen, will negatively affect the way people develop? I mean, I don't inherently have a problem with keeping all my random development stuff locally. git actually does keep all your old commits around when you do a rebase -- they're just not linked anywhere, and they get garbage collected occasionally. (There's no reason someone couldn't build a porcelain on git to make branches for those commits and link them in the comments.) But I wouldn't to have to manually hide all those branches -- I'd want them to disappear by default, as they do with git, unless I actively look for them. Having them not disappear would nudge me in a direction I don't want to go. And as a maintainer of an open-source project I don't want random people on the internet sending me all of the development versions of their patches; I want to see the actual change they're proposing to make to my project, and nothing else. I'm willing to accept that I maybe I just don't understand how your model works; and if I did I'd be less skeptical of it. But having read [1], I'm quite sure you don't understand how my model works, or you wouldn't say it "has no offsetting benefits".