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

Re: How to populate index/worktree when recursive merge merges multiple common ancestors?

From
Christian Halstrick <christian.halstrick@gmail.com>
Date
Jun 30, 2014, 12:48 UTC
Message-ID
<CAENte7i3f_zvPmnPZe2s7guPv03o1d_Ln+nVaj5PYmP8uoK=rw@mail.gmail.com>
In-Reply-To
<CAJo=hJtLzMqrBf5Y1dzUxi_0nGmY72xURRmcvmjoFD+=j0FCwQ@mail.gmail.com>
> They don't. The conflicts are preserved into the virtual ancestor. The
> user only sees the final conflicts during merging of A and B with
> virtual X3 as the common ancestor.

Ah, now I understand. When I merge X1 and X2 into the virtual X3 I should not stop if this is not doable without conflict resolution. I should store in memory the X3 content, including all the conflict markers. If I finally merge A and B I will specify a common base content which may contain conflict markers. Right? Are git config param's like merge.conflictstyle=diff3 are also effective when creating the virtual X3 content? Couldn't that lead to complicated conflict marker situations? In the area where you expect common base content you again see conflict markers in diff3 style.

Previous: Shawn PearceNext: Shawn Pearce
Message 3 of 4 in “How to populate index/worktree when recursive merge merges multiple common ancestors?”
  1. Christian HalstrickJun 27, 2014
  2. Shawn PearceJun 27, 2014
  3. Christian HalstrickJun 30, 2014
  4. Shawn PearceJun 30, 2014

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.