{"thread":{"id":"41958","subject":"Problem with duplicated commits due to a merge","startedAt":"2016-04-07T20:22:07Z","lastAt":"2016-04-07T20:22:07Z","messageCount":1,"participants":["alan@clueserver.org"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"282908","messageId":"5a7a3f4ea2636191c6a42d72b9bb34ab.squirrel@clueserver.org","threadId":"41958","inReplyTo":null,"subject":"Problem with duplicated commits due to a merge","fromName":"","fromEmail":"alan@clueserver.org","sentAt":"2016-04-07T20:22:07Z","receivedAt":"2016-04-07T20:22:07Z","isPatch":false,"sender":{"key":"alan@clueserver.org","avatar":null},"body":"I help manage a Linux kernel repo for a large company. I have encountered\nan odd problem that I think should not exist, but does.\n\nAt one point a merge was done from the development repo to the local\nbranch. Two of the existing commits have the same change to the same\nlocation. At first glance they appear to be the same commit. The have the\nsame author and the same timestamp, but the comments are different and one\npatch has an additional change.\n\nIt looks like an annotate was done to the comments of the local commit,\nwith an additional change picked up in the index. Then they did a git-pull\nwhich merged in all the new commits, as well as the one old commit.\n\nI didn't think that you could do a merge like that without a merge conflict.\n\nThe state of the files at HEAD seem correct, but the double commit causes\nproblems with using git-format-patch. (Both commits show up and wedge when\nthey get applied.)\n\nIs this expected behavior? If so, why?\n\nWe have customers that expect to receive a collection of patches instead\nof a git repo. (Yeah, I know. I am trying to convince them otherwise.)\n\nWhat should happen in this case?\n"}]}