Problem with duplicated commits due to a merge

[alan@clueserver.org]

I help manage a Linux kernel repo for a large company. I have encountered
an odd problem that I think should not exist, but does.

At one point a merge was done from the development repo to the local
branch. Two of the existing commits have the same change to the same
location. At first glance they appear to be the same commit. The have the
same author and the same timestamp, but the comments are different and one
patch has an additional change.

It looks like an annotate was done to the comments of the local commit,
with an additional change picked up in the index. Then they did a git-pull
which merged in all the new commits, as well as the one old commit.

I didn't think that you could do a merge like that without a merge conflict.

The state of the files at HEAD seem correct, but the double commit causes
problems with using git-format-patch. (Both commits show up and wedge when
they get applied.)

Is this expected behavior? If so, why?

We have customers that expect to receive a collection of patches instead
of a git repo. (Yeah, I know. I am trying to convince them otherwise.)

What should happen in this case?