middle-of-am      How to resolve or abort an incomplete am (apply mail)

When conflicting changes are detected, a am 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. Special empty commit case

Sometimes, during a am, the changes in a commit will no longer be
necessary since they have already been included in the code which your
commit is being applied on top of.  In such a case, eg status will simply
show that there are no changes at all, and you can continue by telling git
to skip the current unneeded commit (see below).

4. 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 ********************

1. Standard case

When all conflicts have been resolved, run
  eg am --resolved
Do NOT run "eg commit" to continue an interrupted rebase (unless you want
to manually insert a new commit; if you already accidentally ran eg commit,
then run 'eg reset HEAD~1' to undo it).  If you try to continue without
resolving all conflicts, the command will error out and tell you that some
conflicts remain to be resolved.

2. Special case -- skipping a commit

If you do not want this particular commit to be included in the final
result, run
  eg am --skip

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

To abort your rebase operation, simply run
  eg am --abort