git commit --amend is dangerous
Asked Answered
C

1

11

I sometimes accidentally type git commit -amend when I really wanted to git commit --amend. Git detects that and asks me

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

which is great.

However, sometimes I write git commit -ammend and then git will just accept that and treat my spelling mistake as git -a -m "mend", so it justs commits with the log message "mend".

I am looking for a way to stop git doing so. I've tried to define an alias for git commit -ammend but failed for now. Do you have any suggestions how to deal with this issue?

Clustered answered 22/12, 2016 at 16:40 Comment(5)
Note that the consequences of running git commit -ammend are not as disastrous as you may think. The original commit is the parent of the one you just created by mistake; it didn't go anywhere.Turnbull
@Jubobs I agree but still this is a nuisance.Clustered
@Marina-MSFT Please read carefully. This is what I wrote as well. Btw: Im using git version 2.10.2.windows.1.Clustered
Got it! If you willing to use alias, you can try git config --global alias.amend 'commit --amend'. So every time you need to amend a commit, you just need to use git amend.Catfish
@Marina-MSFT, quoted from below: "Usually I do not want to add too many aliases since then you are learning your git then. What I am dreaming of is an alias that tells me what I did wrong. Then I can benefit on other systems with different gitconfigs as well. So Im still waiting for the perfect answer. Lets see if someone will come up with one."Clustered
B
10

git commit --amend (correctly spelled) is actually more dangerous than git commit -a -m "mend". The former will rewrite an existing commit, replacing it by a new commit, so this is more or less a destructive command. The latter however will just create a commit that you didn’t intend to do. This is a constructive command that does not rewrite any existing history but just adds to it.

Adding a commit that you didn’t intend to add is maybe bothersome but not really problematic at all. You can simply undo that commit (without losing any content) using git reset --soft HEAD~1. This will reset the branch pointer to the commit before without affecting your working directory.

Of course, you can also undo the amendment of a commit but this is more a destructive command with which you need to be a bit careful.

So I personally wouldn’t bother with Git interpreting it the wrong way. Yes, it’s annoying, but that’s all there is to it. Just undo it when you notice it.

What I would personally recommend, especially if you find yourself amending commits more often, to create an alias for git commit --amend. I personally use git amend. You can set this up using the following ocmmand:

git config --global alias.amend "commit --amend"

You can also add -C HEAD if you don’t want to trigger an edit but just want to keep the original commit message (I do this a lot, so this is the alias I am using):

git config --global alias.amend "commit --amend -C HEAD"
Briolette answered 22/12, 2016 at 16:51 Comment(14)
git commit --amend is not destructive.Turnbull
@Jubobs It creates a new commit object with a different id and replaces the old one with the new one. It’s technically as destructive as resetting a branch pointer or deleting a branch. Can you restore that original data? Sure, but that doesn’t make the command less destructive.Briolette
It's not as destructive as, say, git clean -f or git reset --hard HEAD, since you can get back to the original state with the correct sequence of Git-fu commands; that's what I mean.Turnbull
@Jubobs Yes, that’s true. It only affects Git’s graph, not the working directory. (Btw. this is why I wrote “more or less a destructive command”)Briolette
As mentioned above, if you already did the amend commit here is how to recover from it: #34520165Waive
@Briolette If you want to keep the original message, you can use the --no-edit flag.Turnbull
@Jubobs -C HEAD keeps the original committer information though, which is what I usually want.Briolette
Thanks, thats all helpful and correct. And I know how to undo commits. Usually I do not want to add too many aliases since then you are learning your git then. What I am dreaming of is an alias that tells me what I did wrong. Then I can benefit on other systems with different gitconfigs as well. So Im still waiting for the perfect answer. Lets see if someone will come up with one.Clustered
@Clustered Well, it’s not possible to define aliases within subcommands. If you wanted the behavior to change, you would have to change Git’s source.Briolette
I noticed that if you made a branch point from a commit and then do an amend on that commit it changes the commit ID. Is this a dangerous pattern to utilize?Individualize
@Individualize Amending a commit always rewrites the commit, updating the commit time to the current time, which also means that you get a new commit object which its own hash. That’s not dangerous on its own since the content will stay the same, but you should always consider that rewriting history (through amending or rebasing) will likely negatively affect any other developer that already fetched the original commit.Briolette
yea I understand what you mean. What I don't know is if you have a branch that was branched from the old commit hash with then perform an amend on that commit and later on try to merge in the branch into the main chain - would this confuse git in any way.Individualize
@Individualize If both commits (the original and the amended one) are otherwise identical in changes, then Git should be able to detect that, so you shouldn’t get conflicts. If the amended commit has other changes, then you might see conflicts there.Briolette
This looks perfect for keeping my local work up to date in the repo without storing a pile of different commits. (Because I'm not sharing the changes until I finally push)Hood

© 2022 - 2024 — McMap. All rights reserved.