Management of duplicate commits in public repository

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

Management of duplicate commits in public repository

[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