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