On Sat, May 21, 2016 at 12:57:42PM -0400, William Breathitt Gray wrote:
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.
That's very rare, and when it does happen, git handles it automatically just fine. Try it yourself and see.
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?
No, we don't accept commits that are "duplicates".
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?
No, they just aren't there, we don't use cherry-pick at all. Please, look at our trees for proof of this, it's all public :) thanks, greg k-h