34 ms·

Nah, automatic squashing is better. Use multiple stacked pull requests if you want multiple commits.

by sanderjd 3y ago

lmm 3y ago
Why? That's a whole lot of overhead for no gain.
- iwwr 3y ago
  It's far easier for a project with many contributors. Plus, PRs and branches are cheap.
  - sanderjd 3y ago
    I don't think I ever saw one. The director of the product I worked on (comprising a few hundred people spread across a few offices and countries) sat a few "pods" over from me for awhile. He did have priority use of a 1:1 meeting room though.
    - sanderjd 3y ago
      Oops, replied to the wrong comment here. Too late to edit or delete. Oh well.
- sanderjd 3y ago
  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.
        3y ago

Nah, automatic squashing is better. Use multiple stacked pull requests if you want multiple commits.

lmm 3y ago

Why? That's a whole lot of overhead for no gain.

iwwr 3y ago
It's far easier for a project with many contributors. Plus, PRs and branches are cheap.
- sanderjd 3y ago
  I don't think I ever saw one. The director of the product I worked on (comprising a few hundred people spread across a few offices and countries) sat a few "pods" over from me for awhile. He did have priority use of a 1:1 meeting room though.
  - sanderjd 3y ago
    Oops, replied to the wrong comment here. Too late to edit or delete. Oh well.
sanderjd 3y ago
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.
      - 3y ago