undefined | Better HN

0 pointscrimsonnoodle5815d ago0 comments

We're the opposite. No rebasing your PR. It changes the hashes which we use for ci/cd. Keep it linear, show me the full history, show me where you merged main back into it, and then we force squash on merge.

Main then has a nice single commit with a reference to the branch it came from if you wish to see how it developed. Why would we want to litter main with your 100 commits? You own your code, and if you wish to dig into why you did something in a commit, go look in your branch history.

0 comments

4 comments · 2 top-level

hinkley15d ago· 2 in thread

> Main then has a nice single commit with a reference to the branch it came from if you wish to see how it developed.

Yeah sorry that's a toy project. You have 50 people push commits for six years and see if those branches don't 'accidentally' get deleted. We need a different VCS tool to get what you're after there.

jason_oster15d ago

GitHub, Gitea, and Forgejo specifically store all commit hashes for PRs in the `refs/pull/` namespace. The end result is that 50 people pushing commits for six years and deleting all of their branches after squash-and-merge loses no information about how the code evolved.

The main branch remains compact with a linear history without the commit noise. Deleted branches can be restored, commits that otherwise do not exist in the history can be interacted with, and so on.

sn0wleppard15d ago

One of our repos at work (56 contributors) still has all the original branch commits visible on PRs that were squashed and merged in 2018, I've never noticed anything like that being deleted accidentally or otherwise.

sheept15d ago

You can just use --first-parent to skip past commits in merged branches. Squash merges complicate stacked PRs.

But I agree on not rebasing PRs. Another benefit to avoiding force merges is that it's easier for reviewers to compare changes since their last review.

j / k navigate · click thread line to collapse