Management of duplicate commits in public repository

[William Breathitt Gray]

I'm curious how subsystem maintainers typically handle duplicate commits
in their public subsystem repositories. I'm referring to commits which
appear originally in their branch, but are cherry-pick'd to another
subsystem maintainer's repository, and then later merged back in; this
leads to the same textual changes appearing as two distinct commits
after the merge.

In my workflow, I typically rebase against the public repository before
I submit my patches to the subsystem maintainer. In this scenario, the
rebase drops commits which do not produce textual changes in my tree.
Thus, I never have duplicate commit messages in my private repository.

However, a subsystem repository is public, so subsystem maintainers
typically merge new releases of the Linux kernel, rather than rebase,
since history should not be written. If merges are continually
performed, will the subsystem repository not gradually accumulate
duplicate commits over time?

Are the duplicate commits simply accepted as the cost of operating a
public repository, or do the subsystem maintainers make an effort to
remove them before the merge?

William Breathitt Gray