Hi all, git rebase can sometimes "forget" a commit, here is the workflow to reproduce this problem:
$ git init . $ echo "content 1" > file1 $ git add file1 && git commit -m "C1" $ echo "content 2" > file2 $ git add file2 && git commit -m "C2" $ echo "content 3" > file3 $ echo "content 2.3" >> file2 $ git add file3 && git commit -a -m "C3" $ echo "content 4" > file4 $ git add file4 && git commit -a -m "C4" $ git rebase -i HEAD^^ <change "pick" to "edit" for C2> $ echo "content 2" > file3 $ git rebase --continue
Here, we get an error ------ error: The following untracked working tree files would be overwritten by merge: file3 Please move or remove them before you can merge. Aborting Could not apply <hash_C3>... C3 ------ This is expected, as we have created an untracked file which will be created later.
However, if we remove/move away the file3 which conflicts, the "git status" command is misleading, in the sense that it doesn't tell us to run git cherry-pick <hash_C3> Or something approaching. If we don't, then commit <hash_C3> is completely forgotten by the rebasing once we continue it.
Maybe a more explanatory error message would be useful? It is very unclear that the commit won't apply when we continue the rebase workflow.
Kind regards,
-- Ismael