Git Protocol

Rebase does not create readable history except for Open Source Projects that have zillion contributors. For them there is no value in understanding one individual decision, instead they relly on a captain system (git, linux) that forces all changes trough few domain experts.  

For all other teams working on closed source projects, the idea is to never change history. Always keep things traceable. That is why only git has this history rewrite feature. 

I honestly don't care about the merge graph being linear or not while researching reasons why a particular code looks the way it looks. I do care however about seeing the same commit message that the author had made when committing. I also care about seeing the individual change in the same surrounding commit context as the author had made originally. That means no deleting branches (it costs nothing for us to keep them around anyways).

Even if you don't have a habit of creating good commit messages, a history without time travel (git rebase, branch deletes etc) is something that you can reason about.