Never lose a git commit while rebasing
I often interactively rebase git commits at the command line. The editor shows a list of commits. Each entry has one of a few actions. For example, “pick” means to leave the commit alone, while “squash” or “fixup” will combine a commit with another. If you reorder the lines, you reorder the commits.
If you delete a line from the rebase list, git quietly drops that commit, removing those changes–by default, at least. There’s a configuration option, rebase.missingCommitsCheck
, that controls what happens.
If set to “warn”,
git rebase -i
will print a warning if some commits are removed (e.g. a line was deleted), however the rebase will still proceed. If set to “error”, it will print the previous warning and stop the rebase,git rebase --edit-todo
can then be used to correct the error. If set to “ignore”, no checking is done. To drop a commit without warning or error, use the drop command in the todo list. Defaults to “ignore”.
Setting rebase.missingCommitsCheck
to “error” means I need to use the word “drop” to remove a commit on purpose. If I delete a line while rebasing, git will just print an error. Great!
§ How to set it up
You can set rebase.missingCommitsCheck="error"
by running git config --global rebase.missingCommitsCheck error
in your terminal.
There are other ways to set configuration options, and the git book has a gentle introduction to configuring git.
I added rebase.missingCommitsCheck="error"
to my gitconfig years ago, as soon as I found out about it.
The missing commits check was added to Git at the end of June 2015, by Galan Rémi. Thanks!
Recently, I saw the error for the first time, and I was inspired to post this tip. It took an untold number of rebases, but it actually did save me from accidentally dropping a commit!
Have a suggestion? An important correction? Let me know!
If this was helpful or enjoyable, please share it! To get new posts, subscribe to the newsletter or the RSS/Atom feed. If you have comments, questions, or feedback, please email me.