3 ms·

> Some like to rebase, while others prefer to keep the disorganized records. Keeping disorganized records is the only thing you can say in favor of merge commi

by Carrok 2y ago

> Some like to rebase, while others prefer to keep the disorganized records. Keeping disorganized records is the only thing you can say in favor of merge commits, and I'm unconvinced that's a positive thing to begin with.

jaredsohn 2y ago
I think the argument against rebasing is spending time polishing a PR to have a cleaner history for one feature that will maybe get looked at during review (rather than the final output) vs also making a PR for a second feature during that same time. And you can eventually have github squash for you anyway.
- yencabulator 2y ago
  Rebase work resulting in atomic commits != squash
lesuorac 2y ago
Well disorganized records can still be very useful. If you're trying to figure out where a bug came from it can be helpful to bisect through all the commits. If you bisect down to 40 file change that's going to be a pain to continue bisecting. However, if you can bisect down to say 5 changes where your bisection fails and 4 of them are because the app fails to build and the 5th is because that's when the bug was introduced that can be very useful.
- deleted 2y ago
  [deleted]
joe_fishfish 2y ago
You can’t do stacked PRs without merge commits, not unless you really like conflicts anyway.
- seadan83 2y ago
  I have never seen stacked PRs work that well in practice. Two reasons: - Namely there would be review comments on the first PRs that then cause a cascade of merge conflicts in the follow-on PRs - Somehow reviewers never seem to like the stack of PRs, my experience is they always react with disdain and/or confusion. There is the counter-question too, why not stack commits cleanly? A third reason against, not a good reason, but for many developers Git is super difficult (IMO largely a skill issue, not taking the time to learn basic tools that they need everyday; otherwise I have no clue why software developers do not learn their IDEs and VCS tools very well). Stacking PRs requires some Git skills, a simple feature-branch workflow can be a challenge for many.. Ultimately, I think the solution to stacked PRs is to change review policy to "ship/show/ask": https://martinfowler.com/articles/ship-show-ask.html https://martinfowler.com/articles/ship-show-ask.html In other words, if someone is skilled enough to do a set of stacked PRs, the team likely benefits by letting that person merge the stack on their own when each bit is ready and do a post-merge review instead of pre-merge. (Side-note, my unsolicited perspective: I'm personally convinced that the benefits of linear history is a magnitude more important than all the other peeves & nits combined between merge vs rebase.)
  - edfletcher_t137 2y ago
    > - Somehow reviewers never seem to like the stack of PRs, my experience is they always react with disdain and/or confusion. Are people sending multiple branches of the stack for review at once? It should only ever be the "bottom" branch out-for-review at any time. > - Namely there would be review comments on the first PRs that then cause a cascade of merge conflicts in the follow-on PRs This can still happen in the model above of course as you need to make changes to the bottom branch in response to review comments/requests. However, as I noted elsewhere, `--update-refs` is an absolute god-send in those situations: https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/ https://andrewlock.net/working-with-stacked-branches-in-git-... It reduces a ton of manual work (scaled by how many branches you have stacked!) to one operation.
    - seadan83 2y ago

by Carrok 2y ago

jaredsohn 2y ago

I think the argument against rebasing is spending time polishing a PR to have a cleaner history for one feature that will maybe get looked at during review (rather than the final output) vs also making a PR for a second feature during that same time. And you can eventually have github squash for you anyway.

yencabulator 2y ago
Rebase work resulting in atomic commits != squash

lesuorac 2y ago

Well disorganized records can still be very useful. If you're trying to figure out where a bug came from it can be helpful to bisect through all the commits. If you bisect down to 40 file change that's going to be a pain to continue bisecting. However, if you can bisect down to say 5 changes where your bisection fails and 4 of them are because the app fails to build and the 5th is because that's when the bug was introduced that can be very useful.

deleted 2y ago
[deleted]

joe_fishfish 2y ago

You can’t do stacked PRs without merge commits, not unless you really like conflicts anyway.

seadan83 2y ago
I have never seen stacked PRs work that well in practice. Two reasons: - Namely there would be review comments on the first PRs that then cause a cascade of merge conflicts in the follow-on PRs - Somehow reviewers never seem to like the stack of PRs, my experience is they always react with disdain and/or confusion. There is the counter-question too, why not stack commits cleanly? A third reason against, not a good reason, but for many developers Git is super difficult (IMO largely a skill issue, not taking the time to learn basic tools that they need everyday; otherwise I have no clue why software developers do not learn their IDEs and VCS tools very well). Stacking PRs requires some Git skills, a simple feature-branch workflow can be a challenge for many.. Ultimately, I think the solution to stacked PRs is to change review policy to "ship/show/ask": https://martinfowler.com/articles/ship-show-ask.html https://martinfowler.com/articles/ship-show-ask.html In other words, if someone is skilled enough to do a set of stacked PRs, the team likely benefits by letting that person merge the stack on their own when each bit is ready and do a post-merge review instead of pre-merge. (Side-note, my unsolicited perspective: I'm personally convinced that the benefits of linear history is a magnitude more important than all the other peeves & nits combined between merge vs rebase.)
- edfletcher_t137 2y ago
  > - Somehow reviewers never seem to like the stack of PRs, my experience is they always react with disdain and/or confusion. Are people sending multiple branches of the stack for review at once? It should only ever be the "bottom" branch out-for-review at any time. > - Namely there would be review comments on the first PRs that then cause a cascade of merge conflicts in the follow-on PRs This can still happen in the model above of course as you need to make changes to the bottom branch in response to review comments/requests. However, as I noted elsewhere, `--update-refs` is an absolute god-send in those situations: https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/ https://andrewlock.net/working-with-stacked-branches-in-git-... It reduces a ton of manual work (scaled by how many branches you have stacked!) to one operation.
  - seadan83 2y ago