Git: Confusion about merge algorithm, conflict format, and interplay with mergetools

Viewed 1099

I don't know the details, but as far as I understand the process of merging and conflict resolution, it goes as follows (assume there is only one file in the repository, modified in two branches):

  1. The user issues a git merge command.
  2. Git applies some git-specific algorithm to automatically merge the two modified files. For this purpose it creates a BASE, LOCAL, OTHER and BACKUP version of the file.
  3. It then writes the merge result into the original tracked file (call it MERGED).
  4. Assume there are conflicts. Git uses some format to represent the conflict (<<<<<<<, |||||||, =======, >>>>>>> markers). It then sets its status to 'merging' or similar.
  5. If the user then issues git mergetool ... the configured external merge tool opens, with arguments pointing to the BASE, LOCAL, OTHER and of course MERGED.

There are a few points I'm confused about:

  • Will the tool always understand Git's conflict format? Is it standardized? What about the diff3 option? Is it also commonly understood by external tools?
  • Will the tool apply its own (and maybe different) merge algorithm and trash the output of Git entirely?
  • When Git needs to perform a recursive merge (because of several merge bases)—and the intermediate merge creates conflicts—will it treat inner conflict markers as plain text just as any other non-conflicting text? Or is the conflict format recursive itself?

I couldn't find any explanation that really tells the whole story.

2 Answers
Related