3 ms·

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 o

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
      > 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. It really isn't. Branches are just as cheap as commits. It's super easy to create three branches pointing at three arbitrary commits.

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
    > 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. It really isn't. Branches are just as cheap as commits. It's super easy to create three branches pointing at three arbitrary commits.