Look at:
Notice the {f5650163bcea}. This is in the list just once. I searched through history and the entry is not there more times.
Then notice the first one: {a06ce331b098}. This is in the list twice, once from the original author and one merged by Jenkins
Why is this?
This is because if the commit is not on the latest commit that was last merged, then when jenkins submits it, it follows which ever policy is defined for that project, most projects are merge if necessary, which i guess is what happened here.
So this is by design? Maybe jenkins should rebase the change before submitting (if mergeable of course).
The default for all new projects is "Merge if Necessary." That's not configurable as far as I know? Personally, I think the default for all projects should be "Rebase if Necessary."
Jenkins/Zuul doesn't need to handle this, Gerrit can easily.
I remember that changing the "merge if necessary" option to "rebase" caused some issue for @Xqt.
[1]: https://lists.wikimedia.org/pipermail/pywikibot/2017-May/009750.html
Yes as described there this would mixup my local repository, break dependencies and merged patches wouldn’t flagged as merged anymore. On my gui merges can be hidden. I guess there is a git command for it.
The extra commit comes from Gerrit when the change is submitted it will crafts a merge commit if needs be. The behavior is known in Gerrit as the submit type. The default for all project (and for pywikibot/core) is Merge if necessary (see https://gerrit.wikimedia.org/r/admin/repos/pywikibot/core ).
The different types are described at https://gerrit.wikimedia.org/r/Documentation/config-project-config.html#submit-type and Rebase if necessary is the appropriate fix. In this case when a change is not directly on tip of the target branch, Gerrit automatically rebase the patchset and creates a new patchset which keeps a linear history. The drawback is the original patch an author might have locally is NOT in the repository and the dependency chain of patchsets is more or less broken. For all purposes, git rebase locally will happily detects and resolve the issue though.
Marking this task as solved per the discussion link @Dalba provided and @Xqt comment above.