Consider this sequence:
pwd/master$ git add file
pwd/master$ git am 0001-patch.txt
Dirty index: cannot apply patches (dirty: file)
pwd/master|AM$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: file
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# 0001-patch.txt
pwd/master|AM$ git am --abort
pwd/master$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# 0001-patch.txt
# file
"git am" itself correctly detected that the index is dirty, and refrained
from doing anything (other than creating and leaving .git/rebase-apply).
It carefully kept what you added so far to the index.
But "git am --abort" is broken and loses the added changes from the index.
There probably are two possible fixes (I am not familiar with the --abort
that was bolted on recently, and haven't checked the code).
- Perhaps when "git am" fails with a dirty index (i.e. not even starting
to look at the patches and stopping with unapplicable patches), we
should discard .git/rebase-apply directory so that we do not even have
to tell users to run "git am --abort";
- Perhaps "git am --abort" can be told to tell this case from the usual
"patch in progress" case, and act differently.
My preference obviously would be the latter, as .git/rebase-apply/ could
be the only place that has the patches fed to "git am" from its standard
input.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
