Comment by infogulch | Hacker News Reader

Comment by infogulch | Hacker News Reader

Parent Full thread

Github-style rebase-only PRs have revealed the best compromise between 'preserve history' and 'linear history' strategies:

All PRs are rebased and merged in a linear history of merge commits that reference the PR#. If you intentionally crafted a logical series of commits, merge them as a series (ideally you've tested each commit independently), otherwise squash.

If you want more detail about the development of the PR than the merge commit, aka the 'real history', then open up the PR and browse through Updates, which include commits that were force-pushed to the branch and also fast-forward commits that were appended to the branch. You also get discussion context and intermediate build statuses etc. To represent this convention within native git, maybe tag each Update with pr/123/update-N.

The funny thing about this design is that it's actually more similar to the kernel development workflow (emailing crafted patches around until they are accepted) than BOTH of the typical hard-line stances taken by most people with a strong opinion about how to maintain git history (only merge/only rebase).

What's weird about most of these discussions is how they're always seen as technical considerations distinct from the individuals who actually use the system.

The kernel needs a highly-distributed workflow because it's a huge organization of loosely-coupled sub-organizations. Most commercial software is developed by a relatively small group of highly-cohesive individuals. The forces that make a solution work well in one environment don't necessarily apply elsewhere.

I wholeheartedly agree!

With this, you can also push people towards smaller PRs which are easier to review and integrate.

The downside is that if you és o work on feature 2 based on feature 1,either you wait for the PR to be merged in main (easiest approach) or you fork from your feature branch directly and will need to rebase later (this can get messier, especially if you need to fix errors in feature 1).

Git recently added a --update-refs option to rebase that makes dealing with this scenario a lot easier. This post does a good job explaining how to use it: https://andrewlock.net/working-with-stacked-branches-in-git-...

oh my... I was at the point of making a git plugin to do this. This pretty much was the bane of my existence.

:pray:

Git branchless have restack command that restacks whole trees/branches of commits.

Second part explains exactly what I'm juggling with right now.

What about commit signatures? If you rebase, you lose the original signature, don't you?

If you let Github do the rebase, yes, you do. But you can do so manually yourself, taking the commit down to a single squashed commit, that you then sign.

This is a tooling issue that needs to be solved client-side (i.e. where the signing key lives). It's an important one but actually really simple.

I wonder why GitHub doesn’t apply their own signature when they rebase a commit with a valid signature from one of their users. They do that when you edit a file through their Web UI.

This is completely insane under any proposed use case for commit signatures besides "tick some bureaucrat's box that asks 'was the commit signed?'".

Did you even read the article? This article is about perversely forcing the commit hashes to come out a certain way for lulz.

From the guidelines[1]:

> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".

[1]: https://news.ycombinator.com/newsguidelines.html

But why do you "squash" it! Why do people do this?

Ever seen a PR that implements something in a GitHub Actions workflow? The history usually looks like: clear cache, fix path, fix variable expansion, fix command, fix command again, fix syntax, […].

The best way IMO is to interactive-rebase the branch locally (or force-push a rebased version later), but sometimes 50 commits merge into a 30-ligne single-file change and nothing beats squash.

Reply on news.ycombinator.com