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

octopus merge when merged branches have unrelated histories

From
DMDanila Malyutin <danila.malyutin@synopsys.com>
Date
Feb 12, 2019, 13:28 UTC
Message-ID
<0B0D4F5C9DE2CB42B900F670DF730C0B0BBE6D@DE02WEMBXB.internal.synopsys.com>
Hello,

I want to understand if this behavior is as intended: Suppose we have 3 branches A, B, C. A has common history with B and C (due to previous merge, for example), while B and C have unrelated histories. Doing regular simple merge from B into A and then from C into A works smoothly, however when attempting to do an octopus merge into A from B and C simultaneously git complains with "fatal: refusing to merge unrelated histories". With -allow-unrelated-histories git octopus does two simple merges and it works fine.

Is this the intended behavior or is this an oversight? From my point of view the merges are done from branches B and C into A so it shouldn't matter whether B and C have related histories or not (and it doesn't matter in practice as evidenced by successful merge), only if A has related histories with each of them.

Best regards, Danila

Message 1 of 1 in “octopus merge when merged branches have unrelated histories”
  1. Danila MalyutinFeb 12, 2019

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.