git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Problem with duplicated commits due to a merge

From
Aalan@clueserver.org <alan@clueserver.org>
Date
Apr 7, 2016, 20:22 UTC
Message-ID
<5a7a3f4ea2636191c6a42d72b9bb34ab.squirrel@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?
Message 1 of 1 in “Problem with duplicated commits due to a merge”
  1. alan@clueserver.orgApr 7, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.