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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html