Tell HN: Linear history is broken when using GitHub PRs

2 pointsspir2y ago2 comments

Have you ever noticed how GitHub has no fast-forward pull request merges?

Did you know it's impossible to use GitHub PRs without rebasing your dev branch on main after every merged PR?

Please, if anybody knows somebody at GitHub that can help address this glaring limitation (15 years into GitHub's life), please help. My linear history people and I are desperate.

2 comments

2 comments · 1 top-level

akerl_2y ago· 1 in thread

It doesn't sound like your problem is linear history, so much as it's "having multiple long-lived branches".

But also, you should be fine as long as you use merge commits. The thing that will mess up your history is if you let it rebase commits, since then you'll end up with diverged history.

https://docs.github.com/en/pull-requests/collaborating-with-...

spirOP2y ago

I appreciate it, but long-lived branches aren't the problem here.

Let's say you're working on dev, you add two commits, and now you want to merge these to main.

Most people don't know that GitHub has no PR merge method that simply allows you to copy those two commits onto main.

It's literally impossible for you to use GitHub PRs to simply have dev become main.

Here's why:

If you use a merge commit, it will create a merge commit ("The pull request is merged using the --no-ff option.") So dev isn't becoming main; main is becoming something new.

If you use squash and merge, it will rewrite your two commits into a single commit. But you wanted two commits or you would have already done one commit in dev. Again, dev isn't becoming main; main is becoming something new.

If you use rebase and merge, it should then copy your two commits onto main, but in fact, it rewrites them with new commit hashes, it's not a copy. Then, you need to rebase dev back onto main because main is now something new.

More detail: https://github.com/orgs/community/discussions/4618#discussio...

j / k navigate · click thread line to collapse