Git commit --amend merged two commits

Question

I have a remote 'dev' branch and was working on it locally.

I made a first commit on 'dev' with a commit message "my_feature", putting my local branch ahead of the remote by 1 commit.

I then developed some new stuff and made a git add -u, getting ready to commit. I then realized I wanted to rework the previous commit message as "my_feature (1/2)" to make my current commit message as "my_feature (2/2)", putting my local branch ahead of the remote by 2 commits.

So I made a git commit --amend (thinking it would only edit the previous commit's message), edited the "my_feature" commit message as "my_feature (1/2)" and... ended up with a single commit labelled "my_feature (1/2)" having all my changes (first commit + staging files diffs) -- my index is now clean.

So if I got it right, my command actually did a commit, also committed the staging files, which produced a single (merged?) commit?

I was not expecting Git to do such a thing. I just wanted to edit my old commit message, not to merge the old one with my current staging files. (Now that I think about it a rebase could have been better.)

While I can understand why git commit --amend could commit (even if I only wanted to edit a commit message), I have problems to understand how Git merged my two commits into one with a commit command.

Anyone could clarify this to me?

$ git --version
git version 1.7.10.4

Answer 1

If you have staged files and do

git commit --amend

You will create a new commit with everything in the previous commit plus everything staged and this new commit will replace the previous commit as the tip of the branch you have checked out.

git commit --amend without any staged files can be used to change commit message but notice that even in the case where you have no staged files you will get a new sha1, in other words a new commit.

From the documentation:

Used to amend the tip of the current branch. Prepare the tree object you would want to replace the latest commit as usual (this includes the usual -i/-o and explicit paths), and the commit log editor is seeded with the commit message from the tip of the current branch. The commit you create replaces the current tip — if it was a merge, it will have the parents of the current tip as parents — so the current top commit is discarded.