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