While I can't speak for the parent comment, one reason people try to keep clean commit histories in git is that you can easily undo, cherry pick, etc. individual commits.

If all of the changes necessary to add a feature / fix a major bug are in one commit, backporting that commit becomes much easier. If those changes are broken up in multiple commits ("fix this issue" + "oops, forgot that file (and unrelated changes in the same file)"), then it's more trouble. It usually doesn't make sense to have the repository in those intermediate states anyway, once the primary commit is done. History rewriting can make those commits atomic.

Generally speaking, "clean" git histories have relevant history combined, but no significant information lost.

This is definitely true of Postgres, where backporting is relatively common (currently to 5 versions).

Another cultural difference is that the narrative in our commit log has a pretty strong voice. That consistency is valued above individual details about exactly who did what to produce the patch. If you want the details, we have extensive discussions of what lead to a patch on the pgsql-hackers mailing list.

Our archives and threads are pretty well organized. We commonly refer back to threads 3-4 years old when discussing design decisions.

I agree with many of the commenters that it would be nice to have all of the details that lead up to the final patch. Maybe something like a sub-commit history that is generally hidden, but possible to mine when desired. Here my ignorance of git is showing, as I don't know exactly what is possible.

I don't think there's any reason you couldn't have both merges and a clean history.

IIRC the git project itself accomplishes this so that the maintainer forms topic branches from patch series sent to the mailing list (a single patch must still be a self-contained change, so "cleanliness" and bisectability is retained) and then merges those topic branches to whatever branch they're approved for: pu for "proposed updates", "next" for the next "major" release, and "master" for the stable branch. The system is interesting in that "pu" gets completely rebased regularly while next and master have immutable history; and master is periodically merged with next, so that any fixes for the stable branch get propagated into next as well.

Indeed. I don't understand the problem the postgres people had with merge. I'm sure they have their reasons, though.

When people talk about clean commit histories in git, they usually mean rebasing / merging topic branches atomically like we said, though, and Groxx's comment asked about the rationale.

Also keep in mind that a common work flow for tracking down an issue is to revert back to previous versions until you narrow down which one introduced the bug. In that case, you most certainly want fewer, cleaner commits. Narrowing a bug down to a commit that introduced four new features, fixed six bugs, and cleaned up a couple of dozen oopsies in the code base doesn't help you much.

Cleaner commits: agree. But the goal of fewer commits doesn't usually lead to fewer features per commit, rather more.

We strive to have exactly one feature or bugfix per commit. Squashing commits to a single one does not mean we mix stuff randomly.