[saghm]

I guess we just fundamentally disagree with how using git should work. I don't agree at all that using git for a public repo somehow implies that you're committing to preserving every single branch in perpetuity just because the tool can support it. If it's confusing, I'd argue it's from mistakenly inferring that others are conveying intent by publishing public feature branches.

[Pxtl]

That's my core complaint about git's history-destroying behavior. Git wants you to make a clean history, but it also has awful behavior when you modify history that you've started collaborating with people upon.

It is a fundamental flaw. Either git needs to work better at using the history in all of its warty and real glory (for example offering a separate mutable presentation-layer commit-log in front of the immutable data-layer commit-log), or needs to provide better automation and mapping concepts that allow you handle incoming code that has a different history from the current branch.

[GuB-42]

Git doesn't what you to have a clean history. Git just stores all the commits in a DAG structure, and then gives you a lot of freedom in what you make of it.

The git UI however is notoriously terrible, so your complain about presentation is probably justified, but it git itself offers facilities to keep a clean history without clobbering branches without changing the fundamentals.

For example, you can decide to make your clean branches only out of merge commits, so if you look only at the clean branches you will have the nice history you expect, but each commit will have a reference to a parallel ugly branch so you can see everything if you want to, without rewriting. To avoir conflicts polluting your clean branch, first merge the clean branch into the ugly branch, resolve the conflicts and do everything you need to do to stay up to date, then merge back into the clean branch, with a nice merge commit message. The clean branches merge commits are your "presentation layer".

It won't be mutable, but mutable anything is a problem in a distributed system like git that gives you availability but as per the CAP theorem, not consistency.