3 ms·

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

> 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...
- richie_adler 5y ago
  «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.» You can do that in Fossil simply by merging periodically to a separate branch for inspection. You may not now this, but, in Git parlance, all merges in Fossil are "no-ff". When you merge into a branch, you don't get all the commits of the original branch moved to that branch: you merge only the diff. As branches are never deleted in Fossil, you can go check the original development branch if you want. But each merge is the result of all the changes made up to that point. (Unless you cherrypick, of course.)
  - gwd 5y ago
    > You can do that in Fossil simply by merging periodically to a separate branch for inspection. Unfortunately, it's clear that you still don't really understand what I'm talking about.

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

richie_adler 5y ago
«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.» You can do that in Fossil simply by merging periodically to a separate branch for inspection. You may not now this, but, in Git parlance, all merges in Fossil are "no-ff". When you merge into a branch, you don't get all the commits of the original branch moved to that branch: you merge only the diff. As branches are never deleted in Fossil, you can go check the original development branch if you want. But each merge is the result of all the changes made up to that point. (Unless you cherrypick, of course.)
- gwd 5y ago
  > You can do that in Fossil simply by merging periodically to a separate branch for inspection. Unfortunately, it's clear that you still don't really understand what I'm talking about.