[thirdparty/git.git] / Documentation / technical / api-merge.txt

merge API
=========

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>"] recursive` configuration, it will
	be used (see linkgit:gitattributes[5]).

`variant`::
	Resolve local conflicts automatically in favor
	of one side or the other (as in 'git merge-file'
	`--ours`/`--theirs`/`--union`).  Can be `0`,
	`XDL_MERGE_FAVOR_OURS`, `XDL_MERGE_FAVOR_THEIRS`, or
	`XDL_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_merge` that takes the path and
	any merge backend specified in `.gitattributes` or
	`.git/info/attributes` into account.  Returns 0 for a
	clean merge.

Calling sequence:

* Prepare a `struct ll_merge_options` to record options.
  If you have no special requests, skip this and pass `NULL`
  as the `opts` parameter 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.ptr` and `result_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)
Commit	Line	Data
24d113ec JN	1	merge API
	2	=========
	3
	4	The merge API helps a program to reconcile two competing sets of
	5	improvements to some files (e.g., unregistered changes from the work
	6	tree versus changes involved in switching to a new branch), reporting
	7	conflicts if found. The library called through this API is
	8	responsible for a few things.
	9
	10	* determining which trees to merge (recursive ancestor consolidation);
	11
	12	* lining up corresponding files in the trees to be merged (rename
	13	detection, subtree shifting), reporting edge cases like add/add
	14	and rename/rename conflicts to the user;
	15
	16	* performing a three-way merge of corresponding files, taking
	17	path-specific merge drivers (specified in `.gitattributes`)
	18	into account.
	19
712516bc JN	20	Data structures
	21	---------------
	22
	23	* `mmbuffer_t`, `mmfile_t`
	24
	25	These store data usable for use by the xdiff backend, for writing and
	26	for reading, respectively. See `xdiff/xdiff.h` for the definitions
	27	and `diff.c` for examples.
	28
	29	* `struct ll_merge_options`
	30
	31	This describes the set of options the calling program wants to affect
	32	the operation of a low-level (single file) merge. Some options:
	33
	34	`virtual_ancestor`::
	35	Behave as though this were part of a merge between common
	36	ancestors in a recursive merge.
	37	If a helper program is specified by the
	38	`[merge "<driver>"] recursive` configuration, it will
fe77b416	39	be used (see linkgit:gitattributes[5]).
712516bc JN	40
	41	`variant`::
	42	Resolve local conflicts automatically in favor
	43	of one side or the other (as in 'git merge-file'
	44	`--ours`/`--theirs`/`--union`). Can be `0`,
	45	`XDL_MERGE_FAVOR_OURS`, `XDL_MERGE_FAVOR_THEIRS`, or
	46	`XDL_MERGE_FAVOR_UNION`.
	47
	48	`renormalize`::
	49	Resmudge and clean the "base", "theirs" and "ours" files
	50	before merging. Use this when the merge is likely to have
	51	overlapped with a change in smudge/clean or end-of-line
	52	normalization rules.
	53
24d113ec JN	54	Low-level (single file) merge
	55	-----------------------------
	56
	57	`ll_merge`::
	58
	59	Perform a three-way single-file merge in core. This is
	60	a thin wrapper around `xdl_merge` that takes the path and
	61	any merge backend specified in `.gitattributes` or
	62	`.git/info/attributes` into account. Returns 0 for a
	63	clean merge.
	64
712516bc	65	Calling sequence:
24d113ec	66
712516bc JN	67	* Prepare a `struct ll_merge_options` to record options.
	68	If you have no special requests, skip this and pass `NULL`
	69	as the `opts` parameter to use the default options.
	70
	71	* Allocate an mmbuffer_t variable for the result.
	72
	73	* Allocate and fill variables with the file's original content
	74	and two modified versions (using `read_mmfile`, for example).
	75
	76	* Call `ll_merge()`.
	77
	78	* Read the merged content from `result_buf.ptr` and `result_buf.size`.
	79
	80	* Release buffers when finished. A simple
	81	`free(ancestor.ptr); free(ours.ptr); free(theirs.ptr);
	82	free(result_buf.ptr);` will do.
24d113ec JN	83
	84	If the modifications do not merge cleanly, `ll_merge` will return a
	85	nonzero value and `result_buf` will generally include a description of
	86	the conflict bracketed by markers such as the traditional `<<<<<<<`
	87	and `>>>>>>>`.
	88
	89	The `ancestor_label`, `our_label`, and `their_label` parameters are
	90	used to label the different sides of a conflict if the merge driver
	91	supports this.
	92
24d113ec JN	93	Everything else
	94	---------------
	95
	96	Talk about <merge-recursive.h> and merge_file():
	97
	98	- merge_trees() to merge with rename detection
	99	- merge_recursive() for ancestor consolidation
	100	- try_merge_command() for other strategies
	101	- conflict format
	102	- merge options
	103
	104	(Daniel, Miklos, Stephan, JC)