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

git's behaviour during a 'both added' merge conflict

From
JMJeremy Morton <jeremy@configit.com>
Date
Mar 22, 2012, 14:23 UTC
Message-ID
<CAFsnPqrqz+HZGJHWp6YEWKJeXO2jYDw-qYfAdtHhDvYVmeTD1w@mail.gmail.com>

I've noticed that when you're merging and there is a 'both added' merge conflict, git creates the .LOCAL and .REMOTE files for the merge, but not the .BASE file. Now, there isn't an actual base file because the file has been added anew in both branches, but wouldn't it make sense for git to just create an empty .BASE file anyway? Conceptually, new content is being added on both sides to an empty container - the fact that it didn't exist as a file on the filesystem before is something git isn't meant to care about. It also makes things easier for merge tools which are expecting a .BASE file; in practice, scripts just usually create the empty .BASE file anyway. Why not have git do this itself without a script?

Best regards, Jeremy Morton (Jez)

Next: Junio C Hamano
Message 1 of 2 in “git's behaviour during a 'both added' merge conflict”
  1. Jeremy MortonMar 22, 2012
  2. Junio C HamanoMar 22, 2012

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.