23 ms·

> 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

> 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.
- froh 5y ago
  yes agreed. sqlite is tiny in contrast to the kernel. a marvel, created by a small group at a steady pace. in contrast to that the linux kernel patch review workflow lives on history rewrites until all reviewes agree. and most projects I know, kernel included, after this allignment then freeze the history. so its not a "history rewrite all the time" but a commit cleanup rewrite, before final acceptance. in "feature branches", if you wish, and just until the history is helpful for future readers. who cares about typo fixes? for heavens sake, amend them...
- owl57 5y ago
  > That's simply not going to work if you're reviewing dozens of patches a day from random people on the internet. This sounds incapable of producing reliable code even with best tools. Do people actually work this way, as opposed to some deeper hierarchy where maintainers of smaller modules are likely to already know everyone who is going to send non-trivial patches this week?
- Volundr 5y ago
  > 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. I don't understand this comment. What are you looking at if not the total diff when reviewing dozens of branches a day? Once the author has squashed (which as far as I can tell if prevalent) the total diff is all you've got. Fossil on the other hand because it keeps all that history, you can look at the total diff, or look at the path they took to get there. Obviously, git can do this too, just don't squash.
  - gwd 5y ago
    > Once the author has squashed (which as far as I can tell if prevalent) the total diff is all you've got. ... Obviously, git can do this too, just don't squash. You've presented two options: 1. Include every random commit that a person made as they were developing a feature; including ones with bugs, ones they went back and overwrote / changed / whatever 2. Submit the final endpoint of a development branch as one giant squashed patch. This is a false dichotomy. There's a third option: After you as the developer have your giant squashed patch, go through and break it down into individual, reviewable chunks in a logical order. "Reviewable chunk" doesn't mean short necessarily, but that it only contains one "idea" for the reviewer to keep in their head. That's what we insist on in our project. As a kind of extreme example, consider this patch, which is hundreds of lines long, doesn't make any functional change, but is there to make future patches easier to review. The underlying code here is so complicated that either a squashed megapatch or the as-it-was-written development patches would be completely impossible to review. https://xenbits.xenproject.org/xsa/xsa299/0003-x86-mm-Separate-out-partial_pte-tristate-into-indivi.patch https://xenbits.xenproject.org/xsa/xsa299/0003-x86-mm-Separa...
froh 5y ago
maybe team size, project size and pace of change are different in the "home" projects of fossil and git. the patch rewiew workflow of the linux kernel community depends on being able to rework the history until all reviewer agree: this is how this new feature is done, and this is how it is exposed. and then it is added and it history will never be changed again. is that type of workflow possible with fossil? e.g. reworking the history for a feature branch?

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.

froh 5y ago
yes agreed. sqlite is tiny in contrast to the kernel. a marvel, created by a small group at a steady pace. in contrast to that the linux kernel patch review workflow lives on history rewrites until all reviewes agree. and most projects I know, kernel included, after this allignment then freeze the history. so its not a "history rewrite all the time" but a commit cleanup rewrite, before final acceptance. in "feature branches", if you wish, and just until the history is helpful for future readers. who cares about typo fixes? for heavens sake, amend them...
owl57 5y ago
> That's simply not going to work if you're reviewing dozens of patches a day from random people on the internet. This sounds incapable of producing reliable code even with best tools. Do people actually work this way, as opposed to some deeper hierarchy where maintainers of smaller modules are likely to already know everyone who is going to send non-trivial patches this week?
Volundr 5y ago
> 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. I don't understand this comment. What are you looking at if not the total diff when reviewing dozens of branches a day? Once the author has squashed (which as far as I can tell if prevalent) the total diff is all you've got. Fossil on the other hand because it keeps all that history, you can look at the total diff, or look at the path they took to get there. Obviously, git can do this too, just don't squash.
- gwd 5y ago
  > Once the author has squashed (which as far as I can tell if prevalent) the total diff is all you've got. ... Obviously, git can do this too, just don't squash. You've presented two options: 1. Include every random commit that a person made as they were developing a feature; including ones with bugs, ones they went back and overwrote / changed / whatever 2. Submit the final endpoint of a development branch as one giant squashed patch. This is a false dichotomy. There's a third option: After you as the developer have your giant squashed patch, go through and break it down into individual, reviewable chunks in a logical order. "Reviewable chunk" doesn't mean short necessarily, but that it only contains one "idea" for the reviewer to keep in their head. That's what we insist on in our project. As a kind of extreme example, consider this patch, which is hundreds of lines long, doesn't make any functional change, but is there to make future patches easier to review. The underlying code here is so complicated that either a squashed megapatch or the as-it-was-written development patches would be completely impossible to review. https://xenbits.xenproject.org/xsa/xsa299/0003-x86-mm-Separate-out-partial_pte-tristate-into-indivi.patch https://xenbits.xenproject.org/xsa/xsa299/0003-x86-mm-Separa...

froh 5y ago

maybe team size, project size and pace of change are different in the "home" projects of fossil and git. the patch rewiew workflow of the linux kernel community depends on being able to rework the history until all reviewer agree: this is how this new feature is done, and this is how it is exposed. and then it is added and it history will never be changed again. is that type of workflow possible with fossil? e.g. reworking the history for a feature branch?