How Not to Amend a Commit

#What does it mean to amend a commit?

Amending a commit is something that we should do without fear, but depending on the situation I'm sometimes scared. For those of you less familiar with git, amending a commit is just modifying the last commit you have in your history. It's helpful when you realize you missed something that should belong to the previous commit, or when you want to change the commit message.

There's something important to take into account: the amended commit is different than the original one. This should be obvious, but it can lead to ugly situations if the original commit was pushed to a repository. In that case you will have to force push your amended commit, which is something that we try to avoid for reasons.

#The ammend gotcha

But today I wanted to write about some unexpected results if you make a spelling mistake. This is something that has happened to me a couple of times, and it is the reason I'm sometimes scared when I want to amend a commit. TL;DR, don't run git commit -ammend.

If you are a native English speaker, you probably wouldn't do that as you know that "amend" is written with one m, not two. However, if you're not native English speaker, your chances of writing that command are higher. There are infinite good reasons to make mistakes, but there are at least two good reasons that could lead you to make this one.

• Before writing "amend" you have to write "commit". Both words have a pretty similar "m" sound –at least for me– and the first one that you write has two m's. Why shouldn't "ammend amend" be written in the same way?
• Using CLI tools you can often write options with one or two dashes. If you are unsure about amend having one or two m's, it's only human to wonder how many dashes to use. Was it --amend, -amend, --ammend, -ammend?

Those two reason can be intensified when you are going to use a second option, like --no-edit. At that point it's fairly reasonable to doubt about both having one dash, or two, or a combination of them. This concept can take different shapes, but the point is that you have to write a few words and dashes, where you can write one or two m's, or one or two dashes in different places.

But then, what happens if you do git commit -ammend? If you happen to have a mix of staged and unstaged changes, you might have a heart attack. Especially if you spent too much time adding files or patches. Don't worry, you can revert it (the commit, not the heart attack).

The result is that you end up committing all your changes, staged or not, in a new commit. The message of that commit will be "mend" which is a hint of what just happened.

What happened is that git parses the command as git commit -a -m "mend". The first part, -a, is going to add all your changes to be staged. The second part, -m "mend" is going to set "mend" as the commit message. You can see that the resulting command doesn't have --amend, and therefore git will generate a completely new commit.

This can be very fun if you had a few changes but only wanted to commit some of them. It can get even more fun if you are used to insta-push after committing!

#How to prevent it from happening

I wrote about how -ammend is just one of the possible combinations you can write. However, git is protected against other mistakes. For example, this is what happens if you write git -amend or git --ammend:

$ git commit -amend
error: did you mean `--amend` (with two dashes ?)

$ git commit --ammend
error: unknown option `ammend'

So, basically, the only way to write it wrong and get it through is to write -ammend, one dash two m's.

The ways to prevent this gotcha that I could think of are:

• Create a git alias. Something like git amend and git ammend pointing to the right amending command.
• Contribute to the git project to have it throw an error when -ammend is written as option for git commit. It's surprisingly involved the process of contributing to git, and I might be the only person in the world that makes this mistake.