3 ms·

Hmm, I don't think separating independent units of work into separate pull requests is "overhead", I think it is good practice. And the benefit is that instead

Hmm, I don't think separating independent units of work into separate pull requests is "overhead", I think it is good practice. And the benefit is that instead of humans spending time deciding whether or not to squash commits in some branch before merging, or being asked to do so by a maintainer, a computer just does it automatically. It's a lot like automatic code formatting; it's a big win to have tools do things automatically, rather than requiring human time and judgement and communication.

lmm 3y ago
> Hmm, I don't think separating independent units of work into separate pull requests is "overhead", I think it is good practice. They're not independent, they're related. Having multiple levels of "namespace" - repo -> PR -> commit - makes things easier to navigate, just like having multiple levels of folder in your filesystem. > And the benefit is that instead of humans spending time deciding whether or not to squash commits in some branch before merging, or being asked to do so by a maintainer, a computer just does it automatically. If you demand that each PR must be a single commit you just force the human to make that decision earlier and more manually.
- sanderjd 3y ago
  Agree to disagree on the first point. I think if something is enough of an atomic unit to be a good commit in the trunk, then it is a good candidate to be its own pull request, which can be discussed independently. > If you demand that each PR must be a single commit you just force the human to make that decision earlier and more manually. How so? I think you may be misunderstanding the suggestion... The pattern is that people can have whatever commits they want on their own branch, but when that branch gets merged into the trunk, all those commits are automatically squashed into a single one. I don't see how that is "forc[ing] the human to make that decision earlier and more manually".
  - lmm 3y ago
    > The pattern is that people can have whatever commits they want on their own branch, but when that branch gets merged into the trunk, all those commits are automatically squashed into a single one. I don't see how that is "forc[ing] the human to make that decision earlier and more manually". Right, so that means people have to decide whether something's going to be a separate commit immediately when they're working on it, and start a new branch if so. Or they could mess around splitting their branch into smaller branches at the end when they're ready to PR, but that's fiddlier than rebasing to split/merge commits.
    - sanderjd 3y ago
      The up-front process is identical: create a branch to work on something. The development process is identical: create whatever little commits are useful to you personally, don't worry about whether they'll end up in main. At some point you can decide whether you have ended up with another independent unit of work, and point a new branch at the separate unit, without needing to squash any of the commits you have (branches are cheap). I don't know what you mean by making PRs being "fiddler than rebasing to split/merge commits". What is the fiddliness you see?
      - lmm 3y ago
        > At some point you can decide whether you have ended up with another independent unit of work, and point a new branch at the separate unit, without needing to squash any of the commits you have (branches are cheap). That's a horrible way to work because when you squash a branch it breaks the history of any other branch that's based on it. So you'd have to do a fiddly rebase when you merge your first branch in. > I don't know what you mean by making PRs being "fiddler than rebasing to split/merge commits". What is the fiddliness you see? Imagine I've done a bunch of work in a branch, and then decide I want the contents of that branch to become three commits on master. With your workflow I have to split my branch into three branches, retroactively. That's fiddlier than just turning the commits on my branch into three commits.
        sanderjd 3y ago

lmm 3y ago

> Hmm, I don't think separating independent units of work into separate pull requests is "overhead", I think it is good practice. They're not independent, they're related. Having multiple levels of "namespace" - repo -> PR -> commit - makes things easier to navigate, just like having multiple levels of folder in your filesystem. > And the benefit is that instead of humans spending time deciding whether or not to squash commits in some branch before merging, or being asked to do so by a maintainer, a computer just does it automatically. If you demand that each PR must be a single commit you just force the human to make that decision earlier and more manually.

sanderjd 3y ago
Agree to disagree on the first point. I think if something is enough of an atomic unit to be a good commit in the trunk, then it is a good candidate to be its own pull request, which can be discussed independently. > If you demand that each PR must be a single commit you just force the human to make that decision earlier and more manually. How so? I think you may be misunderstanding the suggestion... The pattern is that people can have whatever commits they want on their own branch, but when that branch gets merged into the trunk, all those commits are automatically squashed into a single one. I don't see how that is "forc[ing] the human to make that decision earlier and more manually".
- lmm 3y ago
  > The pattern is that people can have whatever commits they want on their own branch, but when that branch gets merged into the trunk, all those commits are automatically squashed into a single one. I don't see how that is "forc[ing] the human to make that decision earlier and more manually". Right, so that means people have to decide whether something's going to be a separate commit immediately when they're working on it, and start a new branch if so. Or they could mess around splitting their branch into smaller branches at the end when they're ready to PR, but that's fiddlier than rebasing to split/merge commits.
  - sanderjd 3y ago
    The up-front process is identical: create a branch to work on something. The development process is identical: create whatever little commits are useful to you personally, don't worry about whether they'll end up in main. At some point you can decide whether you have ended up with another independent unit of work, and point a new branch at the separate unit, without needing to squash any of the commits you have (branches are cheap). I don't know what you mean by making PRs being "fiddler than rebasing to split/merge commits". What is the fiddliness you see?
    - lmm 3y ago
      > At some point you can decide whether you have ended up with another independent unit of work, and point a new branch at the separate unit, without needing to squash any of the commits you have (branches are cheap). That's a horrible way to work because when you squash a branch it breaks the history of any other branch that's based on it. So you'd have to do a fiddly rebase when you merge your first branch in. > I don't know what you mean by making PRs being "fiddler than rebasing to split/merge commits". What is the fiddliness you see? Imagine I've done a bunch of work in a branch, and then decide I want the contents of that branch to become three commits on master. With your workflow I have to split my branch into three branches, retroactively. That's fiddlier than just turning the commits on my branch into three commits.
      - sanderjd 3y ago