Management of duplicate commits in public repository

[greg@kroah.com (Greg KH)]

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