[josephg]

The problem in my mind is that we’re overloading what a “commit” means. There’s two meanings: either it’s a description of what happened, by some author, at some point in history. Or it’s an atomic feature being added to the codebase.

Commits are the first thing by default. If you squash and rebase them, they become the second thing (feature changes). But in doing so you throw out information about the original history of those changes.

This has always seemed silly to me. Git should just be changed to support both work flows. Keep commits as-is but let me mark a range of commits as being part of feature X, and let me browse the repo from the perspective of those larger feature objects. Or make it so merge / squash commits still reference the individual commit sequence, so I can see what happened in more detail if I want to.

[bonzini]

It already does, using "git merge --no-ff" and "git log --first-parent".