The merge API helps a program to reconcile two competing sets of improvements to some files (e.g., unregistered changes from the work tree versus changes involved in switching to a new branch), reporting conflicts if found. The library called through this API is responsible for a few things.
- 
determining which trees to merge (recursive ancestor consolidation); 
- 
lining up corresponding files in the trees to be merged (rename detection, subtree shifting), reporting edge cases like add/add and rename/rename conflicts to the user; 
- 
performing a three-way merge of corresponding files, taking path-specific merge drivers (specified in .gitattributes) into account.
Data structures
- 
mmbuffer_t,mmfile_t
These store data usable for use by the xdiff backend, for writing and
for reading, respectively.  See xdiff/xdiff.h for the definitions
and diff.c for examples.
- 
struct ll_merge_options
This describes the set of options the calling program wants to affect the operation of a low-level (single file) merge. Some options:
- 
virtual_ancestor
- 
Behave as though this were part of a merge between common ancestors in a recursive merge. If a helper program is specified by the [merge "<driver>"] recursiveconfiguration, it will be used (see gitattributes(5)).
- 
variant
- 
Resolve local conflicts automatically in favor of one side or the other (as in git merge-file --ours/--theirs/--union). Can be0,XDL_MERGE_FAVOR_OURS,XDL_MERGE_FAVOR_THEIRS, orXDL_MERGE_FAVOR_UNION.
- 
renormalize
- 
Resmudge and clean the "base", "theirs" and "ours" files before merging. Use this when the merge is likely to have overlapped with a change in smudge/clean or end-of-line normalization rules. 
Low-level (single file) merge
- 
ll_merge
- 
Perform a three-way single-file merge in core. This is a thin wrapper around xdl_mergethat takes the path and any merge backend specified in.gitattributesor.git/info/attributesinto account. Returns 0 for a clean merge.
Calling sequence:
- 
Prepare a struct ll_merge_optionsto record options. If you have no special requests, skip this and passNULLas theoptsparameter to use the default options.
- 
Allocate an mmbuffer_t variable for the result. 
- 
Allocate and fill variables with the file’s original content and two modified versions (using read_mmfile, for example).
- 
Call ll_merge().
- 
Read the merged content from result_buf.ptrandresult_buf.size.
- 
Release buffers when finished. A simple free(ancestor.ptr); free(ours.ptr); free(theirs.ptr); free(result_buf.ptr);will do.
If the modifications do not merge cleanly, ll_merge will return a
nonzero value and result_buf will generally include a description of
the conflict bracketed by markers such as the traditional <<<<<<<
and >>>>>>>.
The ancestor_label, our_label, and their_label parameters are
used to label the different sides of a conflict if the merge driver
supports this.
Everything else
Talk about <merge-recursive.h> and merge_file():
- 
merge_trees() to merge with rename detection 
- 
merge_recursive() for ancestor consolidation 
- 
try_merge_command() for other strategies 
- 
conflict format 
- 
merge options 
(Daniel, Miklos, Stephan, JC)