Instead of git history, you get a git fairy tale. Practically, the merge conflicts and their resolutions get spread across one or more commits on the branch that was rebased, and the history makes it look like all the work was done after the upstream commit(s) that there was a conflict with. This can be much tidier, but also loses the context of changes. E.g. you can no longer see that something is done differently to everywhere else that does the same thing not because it needs to do it differently, but because it copied and pasted something from ten lines above and the thing ten lines above received a bug fix on another branch which the feature branch was rebased onto. Based on my experience working on large projects that used both approaches, I'd rather scroll past extra commits and squiggly branch lines than try to reconstruct what someone was thinking when they made a mistake without access to the original commit they made the mistake in. If I had to allow history-rewriting operations in git, the one I'd pick would be rewriting the history of Earth so that when history rewriting operations were implemented in git, they defaulted to adding some metadata to the rewritten commits making the operations reversible so I could decide I wanted the real history back.