3 ms·

And then there's tools like Gerrit, which Just Work. Phabricator and GitHub are both very hostile to "stacked diffs".

ajross 6y ago
Github does just fine. It's true that continuous rebasing works poorly in the Github UI (though I still do it anyway), which tends to forget ancestor commits if they get orphaned (you can end up with comments hanging off of stale commits that it forgot). Github's review UI prefers that changes to the PR be presented as new patches and not reworked versions of old ones. I agree this is a poor choice, but it's not about merge strategy. In fact Github, when you apply a pull request, rebases it linearly by default and it goes into the tree the same way a "stacked diff"[1] would, preserving the linear history feature that is the whole point of that strategy. [1] I hate that term, FWIW. The value being provided is a continuous linear history in the main archive, we should call it "branchless" or something instead of naming it after minutiae about how it's implemented.
- xyzzy_plugh 6y ago
  > Github does just fine. I wish this were true, but it's really not. Not remotely. It's garbage. bradfitz's twitter thread[0] does a good job enumerating the problems. My shortlist: unable to comment on arbitrary lines; unable to comment on specific/old commits (surprise! you force pushed and they're gone anyways); > I hate that term, FWIW. The traditional term is "patch set" -- you apply the patches in series. Mailing lists are truly the only good (publicly available) review tool. [0] https://twitter.com/bradfitz/status/1375112189636304898 https://twitter.com/bradfitz/status/1375112189636304898
  - ajross 6y ago
    > I wish this were true, but it's really not. Not remotely Again, you're off on a tangent talking about the Github review UI and not git branching strategies. As far as github: meh. I use it every day to manage large PRs on a large project, and it's fine. Gerrit and mailing list processes fix the problems you have, but have their own pain points. Gitlab is worse than all three. Pick the tools that work for you, adapt to the ones that work for your codevelopers, and don't start fights. Calling someone else's tool garbage helps nothing but your upvote count.
    - xyzzy_plugh 6y ago
      > Again, you're off on a tangent talking about the Github review UI and not git branching strategies. > I use it every day to manage large PRs on a large project, and it's fine. I feel like you're becoming borderline disingenuous here. I demonstrated how Github is not fine, it's actually quite deficient, regardless of your branching strategy. The title of TFA is literally "Stacked Diffs versus Pull Requests". Here's the second line of TFA: "People who have never used it and only use Pull Requests with GitHub/GitLabs generally don’t understand what the fuss is all about." I'm beginning to believe you're those people. > Pick the tools that work for you, adapt to the ones that work for your codevelopers, and don't start fights. Calling someone else's tool garbage helps nothing but your upvote count. I'm not looking to pick a fight here, I'm honestly not sure why any sane person would defend the Github PR workflow. Beyond "it exists" it really doesn't have much going for it. I call it Garbage because that's how I see it. And I hope others see it that way too. And I hope that we as an industry work to build tools that are not Garbage and I hope that those folks mentioned in the article learn to use and experience other tools and realize there is A Better Way to do things. We don't all have to put up with mediocre software. If I see a friend eating literal garbage, I would tell them "hey, you're eating literal garbage, maybe you should stop" and not just keep it to myself.

Github does just fine. It's true that continuous rebasing works poorly in the Github UI (though I still do it anyway), which tends to forget ancestor commits if they get orphaned (you can end up with comments hanging off of stale commits that it forgot). Github's review UI prefers that changes to the PR be presented as new patches and not reworked versions of old ones. I agree this is a poor choice, but it's not about merge strategy. In fact Github, when you apply a pull request, rebases it linearly by default and it goes into the tree the same way a "stacked diff"[1] would, preserving the linear history feature that is the whole point of that strategy. [1] I hate that term, FWIW. The value being provided is a continuous linear history in the main archive, we should call it "branchless" or something instead of naming it after minutiae about how it's implemented.

xyzzy_plugh 6y ago
> Github does just fine. I wish this were true, but it's really not. Not remotely. It's garbage. bradfitz's twitter thread[0] does a good job enumerating the problems. My shortlist: unable to comment on arbitrary lines; unable to comment on specific/old commits (surprise! you force pushed and they're gone anyways); > I hate that term, FWIW. The traditional term is "patch set" -- you apply the patches in series. Mailing lists are truly the only good (publicly available) review tool. [0] https://twitter.com/bradfitz/status/1375112189636304898 https://twitter.com/bradfitz/status/1375112189636304898
- ajross 6y ago
  > I wish this were true, but it's really not. Not remotely Again, you're off on a tangent talking about the Github review UI and not git branching strategies. As far as github: meh. I use it every day to manage large PRs on a large project, and it's fine. Gerrit and mailing list processes fix the problems you have, but have their own pain points. Gitlab is worse than all three. Pick the tools that work for you, adapt to the ones that work for your codevelopers, and don't start fights. Calling someone else's tool garbage helps nothing but your upvote count.
  - xyzzy_plugh 6y ago
    > Again, you're off on a tangent talking about the Github review UI and not git branching strategies. > I use it every day to manage large PRs on a large project, and it's fine. I feel like you're becoming borderline disingenuous here. I demonstrated how Github is not fine, it's actually quite deficient, regardless of your branching strategy. The title of TFA is literally "Stacked Diffs versus Pull Requests". Here's the second line of TFA: "People who have never used it and only use Pull Requests with GitHub/GitLabs generally don’t understand what the fuss is all about." I'm beginning to believe you're those people. > Pick the tools that work for you, adapt to the ones that work for your codevelopers, and don't start fights. Calling someone else's tool garbage helps nothing but your upvote count. I'm not looking to pick a fight here, I'm honestly not sure why any sane person would defend the Github PR workflow. Beyond "it exists" it really doesn't have much going for it. I call it Garbage because that's how I see it. And I hope others see it that way too. And I hope that we as an industry work to build tools that are not Garbage and I hope that those folks mentioned in the article learn to use and experience other tools and realize there is A Better Way to do things. We don't all have to put up with mediocre software. If I see a friend eating literal garbage, I would tell them "hey, you're eating literal garbage, maybe you should stop" and not just keep it to myself.