# git's behaviour during a 'both added' merge conflict 2 messages from 2012-03-22 to 2012-03-22. Participants: Jeremy Morton, Junio C Hamano. Thread: https://gitlist.dev/t/30025 ## Jeremy Morton, 2012-03-22 14:23 Subject: git's behaviour during a 'both added' merge conflict Message-ID: URL: https://gitlist.dev/e/CAFsnPqrqz%2BHZGJHWp6YEWKJeXO2jYDw-qYfAdtHhDvYVmeTD1w%40mail.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) ``` ## Junio C Hamano, 2012-03-22 18:49 Subject: Re: git's behaviour during a 'both added' merge conflict Message-ID: <7vaa38xygt.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vaa38xygt.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Jeremy Morton writes: > 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. Strictly speaking, git doesn't, but I think mergetool may. You may find this thread interesting: http://thread.gmane.org/gmane.comp.version-control.git/188776/focus=188867 which resulted in ec245ba (mergetool: Provide an empty file when needed, 2012-01-19); that change is in v1.7.9.1 and upwards IIRC. ```