Question

In our git repo we accidentally made a commit that deleted all of our files. This commit was pushed to our central server and has been pulled down by other developers and build servers so rewriting the history to undo this is not ideal. Instead we made another rollback commit to restore all of files to their previous state with another attempted rollback commit in between that somehow only restored some files.

cc043989 Rollback commit (goes back to 4bf31def)
f5d7f10e Failed rollback commit
cd60376f Delete all files commit
4bf31def Last good commit
.
.
.

Our concern is whether this will result in any long term impact, specifically with regards to merges to/from feature branches and to/from subtree repos. If it’s going to constantly make merges or something else much more challenging in the future it may be worth just rewriting the history and dealing with the build server/other developer repos manually.

Answer 1

Suppose your history looks like this:

A --- B --- C --- D   master
 \
  E --- F             topic

In commit “B”, you accidentally delete all files. In commit “C”, you restore all files.

When you merge the topic branch into the master branch, you will get many more merge conflicts than you would get otherwise. I suggest rewriting history as if the files were never deleted, since there is no real benefit to keeping that commit around (unless it’s a very public branch).

To delete the commits,

git checkout master
git rebase -i 4bf31def

Then comment out the bad commits:

# cc043989 Rollback commit (goes back to 4bf31def)
# f5d7f10e Failed rollback commit
# cd60376f Delete all files commit
4bf31def Last good commit

The good news is that you can take your time. You can keep working and fix history later, or you can fix it now.