<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">

<article lang="en" id="git-merge-file(1)">
<articleinfo>
    <title>git-merge-file(1)</title>
        <indexterm>
                <primary>git-merge-file(1)</primary>
        </indexterm>
</articleinfo>
<simplesect id="_name">
<title>NAME</title>
<simpara>git-merge-file - Run a three-way file merge</simpara>
</simplesect>
<simplesect id="_synopsis">
<title>SYNOPSIS</title>
<blockquote>
<literallayout><emphasis>git merge-file</emphasis> [-L &lt;current-name&gt; [-L &lt;base-name&gt; [-L &lt;other-name&gt;]]]
        [--attribute-path path] [-p|--stdout] [-q|--quiet]
        &lt;current-file&gt; &lt;base-file&gt; &lt;other-file&gt;</literallayout>
</blockquote>
</simplesect>
<simplesect id="_description">
<title>DESCRIPTION</title>
<simpara><emphasis>git-merge-file</emphasis> incorporates all changes that lead from the <literal>&lt;base-file&gt;</literal>
to <literal>&lt;other-file&gt;</literal> into <literal>&lt;current-file&gt;</literal>. The result ordinarily goes into
<literal>&lt;current-file&gt;</literal>. <emphasis>git-merge-file</emphasis> is useful for combining separate changes
to an original. Suppose <literal>&lt;base-file&gt;</literal> is the original, and both
<literal>&lt;current-file&gt;</literal> and <literal>&lt;other-file&gt;</literal> are modifications of <literal>&lt;base-file&gt;</literal>,
then <emphasis>git-merge-file</emphasis> combines both changes.</simpara>
<simpara>A conflict occurs if both <literal>&lt;current-file&gt;</literal> and <literal>&lt;other-file&gt;</literal> have changes
in a common segment of lines. If a conflict is found, <emphasis>git-merge-file</emphasis>
normally outputs a warning and brackets the conflict with lines containing
&lt;&lt;&lt;&lt;&lt;&lt;&lt; and &gt;&gt;&gt;&gt;&gt;&gt;&gt; markers. A typical conflict will look like this:</simpara>
<literallayout class="monospaced">&lt;&lt;&lt;&lt;&lt;&lt;&lt; A
lines in file A
=======
lines in file B
&gt;&gt;&gt;&gt;&gt;&gt;&gt; B</literallayout>
<simpara>If there are conflicts, the user should edit the result and delete one of
the alternatives.</simpara>
<simpara>The exit value of this program is negative on error, and the number of
conflicts otherwise. If the merge was clean, the exit value is 0.</simpara>
<simpara><emphasis>git-merge-file</emphasis> is designed to be a minimal clone of RCS <emphasis>merge</emphasis>; that is, it
implements all of RCS <emphasis>merge</emphasis>'s functionality which is needed by
<xref linkend="git(1)"/>.</simpara>
</simplesect>
<simplesect id="_options">
<title>OPTIONS</title>
<variablelist>
<varlistentry>
<term>
-L &lt;label&gt;
</term>
<listitem>
<simpara>
        This option may be given up to three times, and
        specifies labels to be used in place of the
        corresponding file names in conflict reports. That is,
        <literal>git merge-file -L x -L y -L z a b c</literal> generates output that
        looks like it came from files x, y and z instead of
        from files a, b and c.
</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>
-p
</term>
<listitem>
<simpara>
        Send results to standard output instead of overwriting
        <literal>&lt;current-file&gt;</literal>.
</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>
-q
</term>
<listitem>
<simpara>
        Quiet; do not warn about conflicts.
</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>
--attribute-path &lt;path&gt;
</term>
<listitem>
<simpara>
        Apply CRLF and other necessary conversions for the <literal>&lt;path&gt;</literal>
        to the result of a merge.
</simpara>
</listitem>
</varlistentry>
</variablelist>
</simplesect>
<simplesect id="_examples">
<title>EXAMPLES</title>
<variablelist>
<varlistentry>
<term>
git merge-file README.my README README.upstream
</term>
<listitem>
<simpara>
        combines the changes of README.my and README.upstream since README,
        tries to merge them and writes the result into README.my.
</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>
git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345
</term>
<listitem>
<simpara>
        merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels
        <literal>a</literal> and <literal>c</literal> instead of <literal>tmp/a123</literal> and <literal>tmp/c345</literal>.
</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>
git merge-file --attr=hello.c -L a -L b -L c tmp/a123 tmp/b234 tmp/c345
</term>
<listitem>
<simpara>
        The same as the above, but make the result suitable to replace
        hello.c in the work tree by applying CRLF and other necessary
        conversions.
</simpara>
</listitem>
</varlistentry>
</variablelist>
</simplesect>
<simplesect id="_author">
<title>Author</title>
<simpara>Written by Johannes Schindelin &lt;<ulink url="mailto:johannes.schindelin@gmx.de">johannes.schindelin@gmx.de</ulink>&gt;</simpara>
</simplesect>
<simplesect id="_documentation">
<title>Documentation</title>
<simpara>Documentation by Johannes Schindelin and the git-list &lt;<ulink url="mailto:git@vger.kernel.org">git@vger.kernel.org</ulink>&gt;,
with parts copied from the original documentation of RCS <emphasis>merge</emphasis>.</simpara>
</simplesect>
<simplesect id="_git">
<title>GIT</title>
<simpara>Part of the <xref linkend="git(1)"/> suite</simpara>
</simplesect>
</article>
