unexpected file deletion after using git rebase --abort

Hello!

I lost a previously untracked file that I added to the index in the
middle of a git rebase --interactive session after a git rebase --abort.
This was unexpected.

    $ ls forgotten_file
    forgotten_file
    $ git rebase --interactive HEAD~3 
      [change first rebase command from pick to  edit]
    $ git add forgotten_file
    $ git rebase --abort
    $ ls forgotten_file
    ls: cannot access forgotten_file: No such file or directory
    $

I was (of course) able to find the SHA-1 of the dangling blob using 'git
fsck', and then retrieve the file using 'git cat-file -p SHA1'

Should this behaviour be considered a bug?  That is, should the contents
of the working directory (including untracked files) before the git
rebase invocation be returned (as if preserved by a git stash
--include-untracked)?  

If we don't expect this, should we update the documentation for the
--abort heading in the git rebase man page to indicate that newly
staged content will be lost after a git rebase --abort?

This is for git version 1.8.3

Paul

--
Paul A. Kennedy
pakenned@pobox.com

Paul A. Kennedy wrote:

If we don't expect this, should we update the documentation for the
--abort heading in the git rebase man page to indicate that newly
staged content will be lost after a git rebase --abort?

How about something along these lines?

diff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt
index 6b2e1c8..dcae40d 100644
--- i/Documentation/git-rebase.txt
+++ w/Documentation/git-rebase.txt

@@ -240,6 +240,9 @@ leave out at most one of A and B, in which case it defaults to HEAD.
 	started, then HEAD will be reset to <branch>. Otherwise HEAD
 	will be reset to where it was when the rebase operation was
 	started.
++
+This discards any changes to files tracked in the working tree or <branch>.
+You may want to stash your changes first (see linkgit:git-stash[1]).
 
 --keep-empty::
 	Keep the commits that do not change anything from its