> You know what I was not interested in? The git history.

Sure, that makes sense, if you’re just interested in the internals, the history doesn’t matter. I get that.

But what do you think about the idea of keeping two views of history? One that’s clean and human-readable, and another that preserves all the detailed commits. With the right filters, you could switch between the simple view and the full story.

EDIT: By the way, I just want to discuss a theory/some thoughts here. There are always pros and cons, and perhaps my text is a little too harshly worded.

I’m dealing with a not so clean history at work, and it’s a lot of hassle and confusion. Although, I’m always ready to reset and go with an alternative solution, for me these abandoned branches are like scrap papers. Good when you’re working on the tasks, worthless when you’re done. If an idea was really good, I’d create a patch or have a proper branch for it.

One thing about code archeology is that you’re not really interested in the diff itself, but the commit description. Which is why an issue tracker can fit that role.

You need time to clean/reorder all those commits, and tools that don't exist yet to handle this double codebase in the hope that it may be useful in the future. Not worth it.