Given three files <current>, <base> and <other>,
git merge-file incorporates all changes that lead from <base>
to <other> into <current>. The result ordinarily goes into
<current>. git merge-file is useful for combining separate changes
to an original. Suppose <base> is the original, and both
<current> and <other> are modifications of <base>,
then git merge-file combines both changes.
A conflict occurs if both <current> and <other> have changes
in a common segment of lines. If a conflict is found, git merge-file
normally outputs a warning and brackets the conflict with lines containing
<<<<<<< and >>>>>>> markers. A typical conflict will look like this:
<<<<<<< A
lines in file A
=======
lines in file B
>>>>>>> B
If there are conflicts, the user should edit the result and delete one of
the alternatives. When --ours, --theirs, or --union option is in effect,
however, these conflicts are resolved favouring lines from <current>,
lines from <other>, or lines from both respectively. The length of the
conflict markers can be given with the --marker-size option.
If --object-id is specified, exactly the same behavior occurs, except that
instead of specifying what to merge as files, it is specified as a list of
object IDs referring to blobs.
The exit value of this program is negative on error, and the number of
conflicts otherwise (truncated to 127 if there are more than that many
conflicts). If the merge was clean, the exit value is 0.
git merge-file is designed to be a minimal clone of RCS merge; that is, it
implements all of RCS merge's functionality which is needed by
git(1).