I've discovered that reordering commits via git rebase -i
may not produce the same end result tree when dealing with removed files - and may do so with no warning or error message.
Take the following sequence of commits
A - Add foo1 B - Add foo2 C - Remove foo2, Add Foo3
Using git rebase -i
to reorder the commits from A-B-C to A-C-B results in foo2 being present in the HEAD.
Is there a way to reorder commits that barks if the reorder would alter the final resulting tree?
I think git rebase
is internally using git am
to apply patches. I don't see any relevant args to git am
that could be used to force a fail upon removal of a non-existent file, which is what I think would be needed. Do I have to patch the git source code to get what I want?