Mastodawn

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

@fishidwardrobe
That merge commit is what git uses to tell the difference between a series of commits and a rebase.

Rebase is just replaying all of the accumulated diffs one by one as new commits and is the strange hack to land on an existing branch.

It is useful, though, in deciding the default direction to merge your work.

You should either merge the existing work, or pretend to start over on top of the existing work.
@foonathan

@Sdowney @foonathan well, personally i'd rather a vcs preseved the actual history of changes; for me that's what it's FOR.

but i know i'm in the minority there.