Hi Blaise On 28/02/2020 17:36, Blaise Garant wrote:
Hello, I don't know if this is a bug but it was unexpected for us. I accidentally added untracked files through a `git add .` while doing an interactive rebase and aborting the rebase deleted those files. Is this to be expected?
I agree that this is surprising and undesirable but it's not unexpected given the way --abort is implemented. 'rebase --abort' calls 'reset --hard <branch we're rebasing>' so it will discard all the uncommitted changes in the worktree and reset the worktree and index to the branch tip.
The tricky thing with your situation is that the files are tracked at the point we call 'reset --hard' as they've been added to the index so git feels free to discard them. Perhaps rather than calling 'reset --hard' it would be better to use a custom callback with unpack_trees() that errors out if there are any paths in the index that are not in HEAD, the commit we just picked or the branch tip we're resetting to. If we do that we should consider using the same thing for 'cherry-pick/merge/reset --abort' as well. --autostash potentially complicates things as the file might be in the stash but not in the other commits but lets not worry about that at the moment.
If your untracked files were ignored then I think 'git add .' would have complained or just not added them, but 'git checkout' and 'git merge' will happily overwrite ignored files so ignoring them is not always an ideal solution.
Best Wishes Phillip
To reproduce: mkdir test_folder cd test_folder git init touch first git add . git commit -m 'First' echo 1 >> first git add . git commit -m 'Second' echo 2 >> first git add . touch second git commit -m 'Third' git rebase -i HEAD~2 #set second to be edited git add . git status #second should have staged git rebase --abort ls #second has been deleted Not sure this is an expected behavior. Thanks Blaise Garant
