I edited an old commit message but git log shows the edited commit with older date higher than commits created more recently

Question

I edited a commit message by running git rebase -i <commit-yesterday> and selecting reword option for rebasing. Afterward, I ran push --force to publish the change to the remote repository. My expectation is that when I run git log, I see a list like the following:

commit 11111111
Date: Today 16:00:00
Message: The commit created Today at 16:00:00

commit 22222222
Date: Today 14:00:00
Message: The commit created Today at 14:00:00

commit 33333333
Date: Today 10:00:00
Message: The commit created Today at 10:00:00

commit 44444444
Date: Yesterday 15:00:00
Message: The message of this commit updated Today at 17:00:00 while it was created yesterday at 15:00:00

But I see the following list that the updated commit is at the top with the old commit date and a new commit ID and the old commit is shown with its old message and old commit ID:

commit 55555555
Date: Yesterday 15:00:00
Message: The message of this commit updated Today at 17:00:00 while it was created yesterday at 15:00:00

commit 11111111
Date: Today 16:00:00
Message: The commit created Today at 16:00:00

commit 22222222
Date: Today 14:00:00
Message: The commit created Today at 14:00:00

commit 33333333
Date: Today 10:00:00
Message: The commit created Today at 10:00:00

commit 44444444
Date: Yesterday 15:00:00
Message: The commit created Yesterday at 15:00:00

Answer 1

Every commit has two date-and-time stamps, not just one. One time stamp is for the author and the other is for the committer. In a new commit you just made from scratch, Git sets author and committer to be the same, and the two time stamps to be the same. Copying a commit, however, results in a new committer (you and now) while preserving the original commit's author and author-time stamps, at least by default.

When you use git rebase, or git commit --amend, to "modify" a commit, you don't actually change the original commit. You can't—nothing can; not even Git itself can change the original commit—so instead, you get a new commit, with a new hash ID, unique to the new commit. The old hash ID is still valid and still refers to the old commit. If the old commit becomes unreachable,¹ it will eventually expire and the old commit will be truly gone, but Git tries hard to keep it around for at least a month or so, in case you change your mind about it and want it back.

What you don't show here is how you are running git log. What Git isn't showing here—because you did not ask for it—is the underlying commit graph. Git is all about commits, and the commits themselves form a Directed Acyclic Graph or DAG. A lot of Git commands and viewers really should show you the graph, because that graph is super-important. The git log command can show you the graph, but you have to ask for it:

git log --graph

or my favorite:

git log --all --decorate --oneline --graph

See Pretty git branch graphs and in particular this answer.

To get Git to show you both date-and-time stamps, add --pretty=fuller and omit --oneline, e.g.:

git log --all --decorate --graph --pretty=fuller

In this case, both your original commit and your reworded commit are still reachable—though exactly how, I can't say without viewing the graph—so you see the reworded commit, with its new hash ID, and showing its new message ... and then you also see the original commit, with its original hash ID, and showing its original message.

A graphical viewer, or running git log with --decorate and --graph, will help explain why you can still see the old commit. Without the graph and its "decorations"—the branch and tag names that allow Git to find commits in the first place, in the jumble of random-looking hash IDs—all we can do is guess why your old commit is also showing up.

---

¹This is a technical term with a rather long definition. See the web site Think Like (a) Git to get started on that.

Answer 2

I found the magic of git log. Since I had rebased the commit, its Commit Date had been changed, but Author Date never changes. However, the command git log sorts commits based on Commit Date (in descending order) but it shows Author Date of commits. This caused confusion. To show both Commit Date and Author Date, use --pretty=fuller option. In other words, running the following command makes all things clear:

git log --pretty=fuller

Usually, Commit Date and Author Date are the same but git rebase, git commit --amend, and cherry-picks are common cases that Commit Date is different from Author Date for a commit.

Answer 3

git rebase -i 44444444 will show the commits from 44444444 without including 44444444. And all the commits from the commit you have edited will be having new hashes now. In your case you will see the latest commit hash also updated.

Edit: I have rerun your scenario and see the output as you expect.

git-test - master ❯ git log --oneline -n 6
78eb09a (HEAD -> master) 222222
6ec4cc9 33333
58d9aea 444444 first message
fc9cae1 oldest


git-test - master ❯ git rebase -i fc9cae1
[detached HEAD 19328bf] 444444 modified message
 Date: Tue Oct 8 14:54:27 2019 +0530
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 b
Successfully rebased and updated refs/heads/master.


git-test - master ❯ git log --oneline -n 6
82b30ed (HEAD -> master) 222222
34c1948 33333
19328bf 444444 modified message
fc9cae1 oldest