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 paken...@pobox.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html