I agree the parent comment is making a great point, but I disagree with its conclusion that "curating the past is wasted effort", because it is tremendously useful if done right, whereas thinking that way creates the problem --a bad history is useless. You can argue the same about documentation, bad documentation is not read, so it is useless to write it (well, in fact you have to write it properly).

The definition of curate is 'to apply selectivity and taste to' a collection, so I'd say it does mean both. I have not built a theory of what is the most useful, but let's take the two extremes. On the one end you have "push only development", that commit bad program states and all their fixes. It's bad because it adds way to much noise to the history. On the other end, you have 'squash only' development, where one polished feature is pushed in one commit. It's a huge diff that carry little more information than the code itself, and loses all subfeatures milestones and discussions, therefore it is mostly useless.

In a way, imagine you have to teach something by demonstration. You don't want the student to get lost by you screwing up the details. You also need to chunk that information into a set of simpler and well-articulated parts. If done well, your git history carries the information of your process in a very similar way.

You have to be somewhere in the middle, so I'd say to do a semantic rebase at last step before merge. A fantastic tool that is not so well-known is git-absorb, which helps a lot doing that cleanly and automatically.

https://github.com/tummychow/git-absorb