middle-of-merge   How to resolve or abort an incomplete merge

When conflicting changes are detected, a merge operation will stop to
allow a user to resolve the conflicts.  At this stage there is one of four
things a user may want to do:
  1) Find out more about what conflicts occurred
  2) Resolve the conflicts
  3) Tell git to complete the operation
  4) Abort the operation
Each will be discussed below.

*************** Find out more about what conflicts occurred ***************

1. Standard case

In order to find out which files have conflicts, run
  eg status
and then look for lines that begin with "unmerged:".  You can then open
the relevant file in an editor and look for lines with conflict markers,
i.e. lines that start with one of
  <<<<<<<
  =======
  >>>>>>>
Between the <'s and the ='s will be one version of the changed file, while
betwen the ='s and the >'s will be another version.

2. Simple tip

Since git will stage any changes it is able to successfully merge, you can
find the unresolved conflict sections of a file by running
  eg diff --unstaged FILE

3. Difficult cases

You can run
  eg ls-files --unmerged
to get a list of all files in the unmerged state.  This will list up to
three lines for each file, and look like the following:
  100644 45b983be36b73c0788dc9cbcb76cbb80fc7bb057 1	foo.C
  100644 ce013625030ba8dba906f756967f9e9ca394464a 2	foo.C
  100644 dd7e1c6f0fefe118f0b63d9f10908c460aa317a6 3	foo.C
The first line corresponds to a version of the file at some common point in
history, the second and third lines correspond to different versions of the
file being merged (relative to the common version).  Each line is of the
form
  mode   internal-object-name                     stage filename
The mode represents the permission bits and or type (executable file,
symlink etc.), the internal-object-name is git's internal name for the
contents of the file, the stage is a simple integer, and you should
recognize the filename.

You can make use of this information to detect the following situations:
  A) There's a conflict in mode change (e.g. removed the executable bit on
     one side of history, turned the file into a symlink in another)
  B) The file is deleted in one version and modified in another (when this
     happens either the 2nd or 3rd stage line will be missing)
Further, you can view the different versions of the file easily, by using
either of:
  eg show :STAGE:FILENAME
  eg show INTERNAL-OBJECT-NAME
Some examples using the output above:
  eg show :2:foo.C
  eg show dd7e1c6f0fefe118f0b63d9f10908c460aa317a6

************************** Resolve the conflicts **************************

1. Standard case.

For each file with conflicts, edit the file to remove the conflict markers
and provide just the correct version of the merged file.  Then run
  eg stage FILE
to tell git that you have resolved the conflicts in FILE.

2. Special cases

Nearly all special cases (and even the standard case) boil down to making
sure the file has the correct contents, the correct permission bits and
type, and then running
  eg stage FILE

If the file is a binary, then there will not be any conflict markers.  In
such a case, simply ensure that the contents of the file are what you want
and then run eg stage, as noted above.

If the file is deleted on one side of history and changed in another,
decide what contents the file should have.  If the correct resolution is to
delete the file, run
  eg rm FILE
Otherwise, put the appropriate contents in the file and run eg stage as
noted above.

If the file has a mode conflict, then fix up the mode of the file (run
'man chmod' and 'man ln' for help on how to do so).  Note that the modes
used by git are as follows:
  100644  --  Normal, non-executable file
  100755  --  File with the executable bit set
  120000  --  symlink
  160000  --  A git submodule (run 'git help submodule' for more info)

******************** Tell git to continue the operation ********************

When all conflicts have been resolved, run
  eg commit

The log message will be pre-populated with a sample commit message for you,
noting the merge and any file conflicts.  If you try to run this command
without resolving all conflicts, the command will error out and tell you
that some conflicts remain to be resolved.

*************************** Abort the operation ***************************

If you had no uncommitted changes before the merge (or do not care about
keeping those changes), you can run
  eg reset --working-copy ORIG_HEAD

If you had uncommitted changes before starting the merge, and have
git-1.6.2 or later, you can try
  eg ls-files --unmerged | awk {'print $4'} | uniq | xargs eg stage
  eg reset --merge ORIG_HEAD
The first command will mark all unmerged files as ready for commit (who
doesn't like having conflict markers in their files?), and the second
command undoes all changes to staged files since ORIG_HEAD -- both the
files that were successfully merged by git, and the files that you manually
staged in the first command.