3 ms·

Splitting changes into multiple commits is a much worse experience if you actually have self-contained dependent changes. 1. The whole review interface isn't s

Splitting changes into multiple commits is a much worse experience if you actually have self-contained dependent changes. 1. The whole review interface isn't set up for reviewing individual commits. 2. You can't merge changes progressively. 3. CI doesn't run on each commit. 4. If you have linear history (good idea IMO) you'll lose your nice commit history when you merge it. This is much better.

beaker52 3mo ago
You can read each individual commit and review the PR as a whole. This is the way many people design and review PRs. You don’t need to merge those changes progressively. If you do, you go through exactly the same process of creating a separate branch and PR. The only difference is that GH has now added some UI and automation for rebasing and merging the PRs. In the past we would have explained the chaining in the PR and rebased manually. You don’t need CI to run on each commit. You only lose your commit history if you squash merge, many people don’t, and you don’t have to either. The arguments come from angle that doesn’t appear to be aware that stacked PRs were a thing before GH made these UX improvements.
- IshKebab 3mo ago
  Look at some level you want a "thing that is reviewed and has CI run on it" right? Unless you work alone you need that. Let us call that unit of work, a flob. When you have written and submitted a flob for review, you often want to continue your work on top of that, and then you may end up with a second dependent flob that is finished before the first flob is merged. You want both to be reviewed. You want CI to run on both. It's simply a much better experience if flobs are PRs rather than commits. I dunno how else to put it. > stacked PRs were a thing before GH made these UX improvements Not in a way that worked properly. You could sort of do it for PRs within a fork, but it was impossible across forks which is the way most open source GitHub PRs are done.
  - beaker52 3mo ago
    > Look at some level you want a "thing that is reviewed and has CI run on it" right? Yeah, it’s called a branch, or PR. It’s a set of changes you want to sign off. It seems like you want CI run on every commit, which seems rather unnecessary. And if you don’t, well, that’s always been the case. > Not in a way that worked properly. GitHub operates git. No git changes have happened. It’s just commits and branches, in git. So anything that worked before, works exactly the same now, but with buttons taking out some of the small amount of effort you had to put in.
    - IshKebab 3mo ago
      [dead]

beaker52 3mo ago

You can read each individual commit and review the PR as a whole. This is the way many people design and review PRs. You don’t need to merge those changes progressively. If you do, you go through exactly the same process of creating a separate branch and PR. The only difference is that GH has now added some UI and automation for rebasing and merging the PRs. In the past we would have explained the chaining in the PR and rebased manually. You don’t need CI to run on each commit. You only lose your commit history if you squash merge, many people don’t, and you don’t have to either. The arguments come from angle that doesn’t appear to be aware that stacked PRs were a thing before GH made these UX improvements.

IshKebab 3mo ago
Look at some level you want a "thing that is reviewed and has CI run on it" right? Unless you work alone you need that. Let us call that unit of work, a flob. When you have written and submitted a flob for review, you often want to continue your work on top of that, and then you may end up with a second dependent flob that is finished before the first flob is merged. You want both to be reviewed. You want CI to run on both. It's simply a much better experience if flobs are PRs rather than commits. I dunno how else to put it. > stacked PRs were a thing before GH made these UX improvements Not in a way that worked properly. You could sort of do it for PRs within a fork, but it was impossible across forks which is the way most open source GitHub PRs are done.
- beaker52 3mo ago
  > Look at some level you want a "thing that is reviewed and has CI run on it" right? Yeah, it’s called a branch, or PR. It’s a set of changes you want to sign off. It seems like you want CI run on every commit, which seems rather unnecessary. And if you don’t, well, that’s always been the case. > Not in a way that worked properly. GitHub operates git. No git changes have happened. It’s just commits and branches, in git. So anything that worked before, works exactly the same now, but with buttons taking out some of the small amount of effort you had to put in.
  - IshKebab 3mo ago
    [dead]