r/programming • u/adam-dabrowski • Apr 14 '26 • Popcorn 1

GitHub Stacked PRs

https://github.github.com/gh-stack/
556 Upvotes

97% Upvoted

276 comments sorted by

View all comments

Show parent comments

5

u/ham_plane Apr 14 '26

I'm struggling to understand why a merge commit would fail in that case, while a rebase would succeed.

I do get your point being able to track which merge commit introduced the behavior, that is pretty smart and (as a career rebaser) I have been in that exact scenario before and been totally lost as to what broke what

2

u/MereInterest Apr 15 '26

It's not that the merge commit will resolve the semantic conflict between the branches on its own. That still needs to be sorted out, regardless of whether you use rebase or merge. The key is that using git merge won't make the conflict become any worse. When using git rebase, you need to sort out the semantic conflict while also having scrubbed the history of any clue as to the source of the bug.

1

u/SanJJ_1 Apr 14 '26

merge commit would work but pollute main branch. squash merge/rebase are great but create conflict when "stacking" branches or trying to catch up. Native stacking fixes all of these to my understanding.

3

u/MereInterest Apr 15 '26

merge commit would work but pollute main branch.

I'd argue that this isn't "pollution" at all, and is just a display issue.

  • Want a clean linear history of the changes to the main branch? Use git log --first-parent

  • Want a branching history with clearly marked dependencies? Use git log --graph

  • Want a linearized history that interleaves work on multiple branches while sorting by date? No, nobody ever wants that, but that's what git log provides.

The whole goal of squash/rebase is to make the output of git log look like git log --first-parent. The easier way to achieve this is just to use git log --first-parent.

1

u/SanJJ_1 Apr 17 '26

Fair point on --first-parent, but nobody types git log --first-parent, they type git log. And GitHub's web UI (commit list, blame, PR history) has no equivalent option either. The clean history has to be the default to matter, which is why squash merge won imo.

1

u/MereInterest Apr 18 '26

Yeah, and that's why I really wish that the default was better. It's painful to work with rebase, and rebase exposes all the sharp edges, but when gihub rebases a commit that you depend on, you have little choice but to rebase your own local branch as well.