3 ms·

> But if it's so big you need to do that, it should be separate PRs anyway really. The problem with that in practice is that the commits often depend on each o

> But if it's so big you need to do that, it should be separate PRs anyway really. The problem with that in practice is that the commits often depend on each other and then you have a choice of: - serializing the PRs, i.e. only have one PR outstanding at a time, which increases your development latency; or - no native UI for tracking how the PRs relate to each other Yes, there are people trying to hack around the second problem. Still, the story there is far from great. The CI thing is a real issue, I'll give you that. Though it is obviously also solvable, if the will for it were to exist.

IshKebab 3y ago
> serializing the PRs, i.e. only have one PR outstanding at a time, which increases your development latency I don't see a significant downside to this. It doesn't affect my development latency - if the commits depend on each serially other then you have to wait for them to be reviewed in order whether or not they are separate PRs. I do agree that GitHub/Gitlab don't support dependent PRs very well. You pretty much have to wait for one to be merged before submitting the next. Not a big problem in practice but it could definitely be improved.
- TheCleric 3y ago
  Once you start doing serialized PRs then doing squash merges increases your chance of a nightmare. For example you have PR 1 and PR 2 (based on 1). Squash merge PR 1 into main. But while 2 is under review someone merges in 3 into main and you need to bring it into 2 to resolve some conflicts. You’re now hosed because the changes done in 1 are now present TWICE. First in 1’s commit, and also in the squash commit. Now you’re resolving all of 1’s changes as merge conflicts. This may sound like a contrived examples but it has happened to me EVERY time I’ve worked somewhere that demands squash commits. And this is one of the reasons I hate squash commits. “Makes the history prettier” vs “Rewriting the actual commit history”. Telling the truth > pretty.
  - IshKebab 3y ago
    Ah I think where you're going wrong is trying to merge master into PR 2. Instead you should just rebase PR 2 on top of master. Git will automatically figure out that PR 1 has been merged and drop it. If it doesn't for some reason you can just do an interactive rebase. Git history isn't "the truth" until it's shared. There's absolutely no issue rewriting history history for your own edits that nobody else is using yet. You do that every time you press undo!
    - atq2119 3y ago
      > Git will automatically figure out that PR 1 has been merged and drop it. Unfortunately, that part doesn't work if you let GitHub do a squash, because then the commit on main has no corresponding commit on (the branch of) PR2. When cherrypicking the commits corresponding to PR1 during the rebase, the merge algorithm will notice that the change is already there and notify you of the empty commit if the change is completely identical. But if it isn't, that falls down. It's still not too difficult to recover, but it's annoying.
    - IshKebab 3y ago
      > Unfortunately, that part doesn't work if you let GitHub do a squash, because then the commit on main has no corresponding commit on PR2. Did you try it? It does still work. Git will detect that the changes are identical and drop it, even if the commit hash is different.

IshKebab 3y ago

> serializing the PRs, i.e. only have one PR outstanding at a time, which increases your development latency I don't see a significant downside to this. It doesn't affect my development latency - if the commits depend on each serially other then you have to wait for them to be reviewed in order whether or not they are separate PRs. I do agree that GitHub/Gitlab don't support dependent PRs very well. You pretty much have to wait for one to be merged before submitting the next. Not a big problem in practice but it could definitely be improved.

TheCleric 3y ago
Once you start doing serialized PRs then doing squash merges increases your chance of a nightmare. For example you have PR 1 and PR 2 (based on 1). Squash merge PR 1 into main. But while 2 is under review someone merges in 3 into main and you need to bring it into 2 to resolve some conflicts. You’re now hosed because the changes done in 1 are now present TWICE. First in 1’s commit, and also in the squash commit. Now you’re resolving all of 1’s changes as merge conflicts. This may sound like a contrived examples but it has happened to me EVERY time I’ve worked somewhere that demands squash commits. And this is one of the reasons I hate squash commits. “Makes the history prettier” vs “Rewriting the actual commit history”. Telling the truth > pretty.
- IshKebab 3y ago
  Ah I think where you're going wrong is trying to merge master into PR 2. Instead you should just rebase PR 2 on top of master. Git will automatically figure out that PR 1 has been merged and drop it. If it doesn't for some reason you can just do an interactive rebase. Git history isn't "the truth" until it's shared. There's absolutely no issue rewriting history history for your own edits that nobody else is using yet. You do that every time you press undo!
  - atq2119 3y ago
    > Git will automatically figure out that PR 1 has been merged and drop it. Unfortunately, that part doesn't work if you let GitHub do a squash, because then the commit on main has no corresponding commit on (the branch of) PR2. When cherrypicking the commits corresponding to PR1 during the rebase, the merge algorithm will notice that the change is already there and notify you of the empty commit if the change is completely identical. But if it isn't, that falls down. It's still not too difficult to recover, but it's annoying.
  - IshKebab 3y ago
    > Unfortunately, that part doesn't work if you let GitHub do a squash, because then the commit on main has no corresponding commit on PR2. Did you try it? It does still work. Git will detect that the changes are identical and drop it, even if the commit hash is different.