Repository navigation
Adopt linear history in lang-team repo #381
Description
Implemented in rust-lang/team#2538. I created this issue to nominate so we can discuss in the next lang team meeting.
We don't use bors, so all three options to merge a pull request appear today. Historically PRs have used merge commits, but this was not enforced.
There's not a need for merge commits in a repo as simple as lang-team, and there's not an option to require them for consistency either. For simplicity, let's disallow future merge commits and keep a linear history.
Activity
traviscross commentedon Jul 1, 2026
I'm not sure that this makes sense from a process perspective. Merge commits track who merged the PR and when. This is easy to lose in the git history without that. For process-relevant items such as #382, that's metadata that I want.
I could get behind semi-linear history, though (i.e., keeping merge commits when appropriate but requiring the branch be fully rebased before the merge).
BurntSushi commentedon Jul 1, 2026
@traviscross I think the merger should be tracked in the commit metadata.
rust-lang/regexbans merge commits but my name shows up for merging PRs authored by someone else. For example: rust-lang/regex@468fc64(I'm not sure if this helps, sorry to butt in here.)
joshtriplett commentedon Jul 1, 2026
👍 for having merge commits as a record. Regarding requiring rebases, shrug; no fundamental objection, but having to rebase is not always awesome, if the PR applies and it is potentially useful what it was based on. I'd be all for (for instance) prohibiting backmerges, though.
tgross35 commentedon Jul 3, 2026
Just noting that GH does this automatically with rebase merges (we do the same for
libchttps://github.com/rust-lang/libc/commits/main/), which means you can see who wrote it and who merged it in the same place rather than split:(ditto from me, stumbled across this scanning the lang meetings)
tmandry commentedon Jul 18, 2026
My primary goal is to be consistent, and the current setup doesn't enforce that. I realized recently that merge queue could be used to enforce consistent merge commits. Linear history would be my preference in a vacuum for this repo, and good points on the committer metadata. But since merge commits are consistent with the history, I think I will go with that.