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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
