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.
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.
@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 ;)