Make a diff with amend commit

Question

I wonder is that possible to show diff between two commits one of what is amend ? In other words does git save amended commits in history somewhere?

Answer 1

An amended commit is no different than any other commit. In that sense it is perfectly possible to diff between a 'normal' commit and a commit that was amended.

In other words does git save amended commits in history somewhere?

There is not some list that holds all the commits that were amended, no. Amended commits are in the history just like all other commits.

When you amend a commit, it basically gets removed and replaced by a new one (it also gets a new commit hash) that has the changes from the original commit + the amended changes.

In the git reflog you can see your recent actions, and that does show the amending of commits. References from there can be used to for example undo a git commit --amend. Also see How to undo "git commit --amend" done instead of "git commit" for more details about that.

Answer 2

I don't think I understand the question, but I think part of that is because I think you have the wrong idea of what git commit --amend does.

A commit, in git, can't actually be changed. All that git commit --amend does is to write the new commit with a deliberately-altered parent ID.

Let's take a look at the normal process for making a new commit.

Before you make the new commit, you modify some file(s) in your work-tree, then you use git add to stage these changes, so that the new versions of the files will be committed. This git add puts the new version of the file into git's "index", i.e., its staging area.

Files that were already in the previous commit are already in the staging area. So the new commit you will make will have all the original files, except that anything you changed and then git add-ed will be the new version instead of the old version.

Now you run git commit (without --amend) and git does the following:

• collect a commit message (from -m, -F, or running your editor);
• get your name and email, and the current time;
• get the SHA-1 ID of the current commit (not the new one);
• use the staging area to write a "tree" object: this is the source tree that will be associated with the new commit;
• create a commit object with all of this information (author+committer, tree, parent ID, and your message)—this new commit object has a new unique SHA-1 ID;
• and finally, write the new ID into the branch, so that the branch label points to the new ID instead of what used to be the tip-most branch.

The last step "grows the branch", so that if you used to have some commits, something like this:

... <- E <- F <- G   <-- master

you now have one more:

... <- E <- F <- G <- H   <-- master

The branch name (master or whatever it may be) now points to your newest commit H, and H points back to what used to be your newest commit G.

If you use git commit --amend, git changes this sequence just one tiny bit: instead of making the new commit (H) point back to the current one (G), git makes the new one point back to the current one's parent (in this case, F):

                G
              /
... <- E <- F <- H   <-- master

Now master (or whatever branch you're on) points to H, which points to F, and so on.

If you run git log, git starts with the current commit (H) and logs it, and then moves to its parent (F) and logs it, and so on. Commit G seems to be gone.

The SHA-1 ID for G is still around (for 30 days by default), in the "reflogs". There's a reflog for HEAD, and one for your current branch. If you're on branch master and you've just made H, then master@{1} is the previous tip of master, which is commit G. Or, if you have the SHA-1 ID saved somewhere on your screen, you can cut-and-paste it to see commit G.

(The --amend switch can also amend a merge commit. This works exactly the same way as above, it just means that git has to copy all the parent IDs from the old branch-tip to the new one.)