Hacker News Reader

In fact, for searching how a file got to the state it is I prefer that when PRs are merged, they are merged and not rebased. I want the commit shas to be the same.

Rebasing on main loses provenance.

If you want a clean history doing it in the PR, before merging it. That way the PR is the single unit of work.

View on HN

Merging a PR with rebase doesn't lose provenance. You can just keep all the commits in the PR branch. But even if you squash the branch into a single commit and merge (which these tools automate and many people do), it still doesn't lose provenance. The provenance is the PR itself. The PR is connected to a work item in the ticketing system. The git history preserves all the relevant info.

The provenance that is lost is the original base.

No, the original base is in the commit history. It's just not relevant any more after rebase. It's like your individual keystrokes before a commit are not relevant any more after a commit. They're not lost provenance.

> That way the PR is the single unit of work.

Well if I have a diff of the PR with just the changes, then the PR is already a "unit of work," regardless of merge or rebase, right?

Reply on news.ycombinator.com