<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sect2 SYSTEM "../../../dtd/dblite.dtd">

<sect2 lang="en" id="git-merge-index(1)">
    <title>git-merge-index(1)</title>
    <date>2024-07-02</date>
<revhistory><revision><date>2024-07-02</date></revision></revhistory>
<indexterm>
<primary>git-merge-index(1)</primary>
</indexterm>
<simplesect id="git-merge-index(1)__name">
<title>NAME</title>
<simpara>git-merge-index - Run a merge for files needing merging</simpara>
</simplesect>
<simplesect id="git-merge-index(1)__synopsis">
<title>SYNOPSIS</title>
<blockquote>
<literallayout><emphasis>git merge-index</emphasis> [-o] [-q] &lt;merge-program&gt; (-a | ( [--] &lt;file&gt;&#8230;) )</literallayout>
</blockquote>
</simplesect>
<simplesect id="git-merge-index(1)__description">
<title>DESCRIPTION</title>
<simpara>This looks up the &lt;file&gt;(s) in the index and, if there are any merge
entries, passes the SHA-1 hash for those files as arguments 1, 2, 3 (empty
argument if no file), and &lt;file&gt; as argument 4.  File modes for the three
files are passed as arguments 5, 6 and 7.</simpara>
</simplesect>
<simplesect id="git-merge-index(1)__options">
<title>OPTIONS</title>
<variablelist>
<varlistentry>
<term>
--
</term>
<listitem>
<simpara>
        Do not interpret any more arguments as options.
</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>
-a
</term>
<listitem>
<simpara>
        Run merge against all files in the index that need merging.
</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>
-o
</term>
<listitem>
<simpara>
        Instead of stopping at the first failed merge, do all of them
        in one shot - continue with merging even when previous merges
        returned errors, and only return the error code after all the
        merges.
</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>
-q
</term>
<listitem>
<simpara>
        Do not complain about a failed merge program (a merge program
        failure usually indicates conflicts during the merge). This is for
        porcelains which might want to emit custom messages.
</simpara>
</listitem>
</varlistentry>
</variablelist>
<simpara>If <emphasis>git merge-index</emphasis> is called with multiple &lt;file&gt;s (or -a) then it
processes them in turn only stopping if merge returns a non-zero exit
code.</simpara>
<simpara>Typically this is run with a script calling Git's imitation of
the <emphasis>merge</emphasis> command from the RCS package.</simpara>
<simpara>A sample script called <emphasis>git merge-one-file</emphasis> is included in the
distribution.</simpara>
<simpara>ALERT ALERT ALERT! The Git "merge object order" is different from the
RCS <emphasis>merge</emphasis> program merge object order. In the above ordering, the
original is first. But the argument order to the 3-way merge program
<emphasis>merge</emphasis> is to have the original in the middle. Don't ask me why.</simpara>
<simpara>Examples:</simpara>
<screen>torvalds@ppc970:~/merge-test&gt; git merge-index cat MM
This is MM from the original tree.              # original
This is modified MM in the branch A.            # merge1
This is modified MM in the branch B.            # merge2
This is modified MM in the branch B.            # current contents</screen>
<simpara>or</simpara>
<screen>torvalds@ppc970:~/merge-test&gt; git merge-index cat AA MM
cat: : No such file or directory
This is added AA in the branch A.
This is added AA in the branch B.
This is added AA in the branch B.
fatal: merge program failed</screen>
<simpara>where the latter example shows how <emphasis>git merge-index</emphasis> will stop trying to
merge once anything has returned an error (i.e., <emphasis>cat</emphasis> returned an error
for the AA file, because it didn't exist in the original, and thus
<emphasis>git merge-index</emphasis> didn't even try to merge the MM thing).</simpara>
</simplesect>
<simplesect id="git-merge-index(1)__git">
<title>GIT</title>
<simpara>Part of the <xref linkend="git(1)" /> suite</simpara>
</simplesect>
</sect2>
