Adopt linear history in lang-team repo

[tmandry]

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.

[traviscross]

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]

@traviscross I think the merger should be tracked in the commit metadata. rust-lang/regex bans 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]

👍 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]

@traviscross I think the merger should be tracked in the commit metadata. rust-lang/regex bans merge commits but my name shows up for merging PRs authored by someone else. For example: rust-lang/regex@468fc64

Just noting that GH does this automatically with rebase merges (we do the same for libc https://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:

$ git log --format=fuller 468fc64 -1
commit 468fc64ecd6493caaca40dbe8319c31c5c08a83d
Author:     dxbjavid <...>
AuthorDate: Thu Jun 11 ...
Commit:     Andrew Gallant <...>
CommitDate: Mon Jun 22 ...

    automata: reject dense DFA start states that are match states

    ...

(I'm not sure if this helps, sorry to butt in here.)

(ditto from me, stumbled across this scanning the lang meetings)

[tmandry]

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.