Git linear history is a recommendation to disguise the real reasons for change for code, and to lie about the true history of the code.

All of the commits on `main` should be signed merges.

All commits on `main` are production code.

#HillToDieOn

@Sdowney So you want a history like:

* Add new feature X (doesn't compile yet)
* Fix prerequisite feature Y that was required
* Continue work on X
* Fix typo in the documentation

over

* Fix feature Y in the edge case E
* Add new feature X

@foonathan @Sdowney i think not. i think it's rather an argument for squash commits instead of rebases.

or, you know, use a vcs with real branches that don't collapse into the trunk when you merge ;)

@foonathan @Sdowney if it doesn't compile yet, how is the code being merged in main?