git - reorder commits safely

Question

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?

Answer 1

did you make the contents of the files differ by a lot? It can be seen as a move if they are too similar. You should get stopped with a conflict when you try and apply a patch to remove a file that's not there.

Hope this helps.

Answer 2

You can rebase, compare the result, and then possibly reset to the old state. A simple combination of

• git stash save --include-untracked to get into a clean state
• git rev-parse HEAD to get the hash of the current commit
• git rebase to do the real work
• git checkout the_previously_saved_hash . to restore the state before rebasing
• git clean -fd to get rid of all superfluous files
• git commit -m "Undoing the changes introduces by rebase." which may fail if the rebase introduced no changes (this failure can be silently ignored)
• git stash pop to re-introduce the stashed-away "pollution"

should do... I guess I'll try to make a script like this soon as it's something I need as well.