DEV Community: Alex

How to Change the Date of an Old Git Commit

Alex — Fri, 10 Jul 2026 22:16:45 +0000

Sooner or later, most Git users encounter a situation where a commit has the wrong timestamp.

Maybe your system clock was incorrect.

Maybe you imported commits from another repository.

Maybe you rebased a branch and unexpectedly changed commit dates.

Or maybe you're simply curious about how Git stores commit metadata.

In this article, we'll look at how to change the date of an old Git commit and why the process is more complicated than most developers expect.

Why Git Commit Dates Matter

Every Git commit contains more than just code changes.

A commit also stores metadata, including:

Author
Committer
Author Date
Commit Date
Commit Message

You can inspect a commit with:

git show --pretty=fuller HEAD

Example:

AuthorDate: Mon Jul 1 10:00:00 2026 +0000
CommitDate: Mon Jul 1 10:00:00 2026 +0000

These timestamps become part of the commit object itself.

This means changing a date creates a new commit hash.

We'll come back to that later.

Changing the Date of the Last Commit

If you only need to modify the most recent commit, Git provides a relatively straightforward solution.

GIT_COMMITTER_DATE="2026-07-01T10:00:00" \
git commit --amend --no-edit --date="2026-07-01T10:00:00"

After running the command:

Author Date is updated
Commit Date is updated
Commit hash changes

You can verify the result:

git show --pretty=fuller HEAD

For a single commit, this approach is usually sufficient.

Changing the Date of an Older Commit

Things become more complicated when the commit is not the latest one.

Imagine a history like this:

A
B
C
D
HEAD

Suppose you want to change the date of commit B.

Git cannot simply modify that commit in place.

Instead, Git must rewrite history.

The typical approach is:

git rebase -i HEAD~4

Git will open an editor:

pick A
pick B
pick C
pick D

Change the target commit:

pick A
edit B
pick C
pick D

Save and exit.

Git stops at commit B.

Now amend the date:

GIT_COMMITTER_DATE="2026-07-01T10:00:00" \
git commit --amend --no-edit --date="2026-07-01T10:00:00"

Continue the rebase:

git rebase --continue

Git rebuilds the remaining commits on top of the modified commit.

Why This Changes Commit Hashes

Many developers are surprised by what happens next.

The code hasn't changed.

The files haven't changed.

The commit message hasn't changed.

Only the timestamp changed.

Yet Git generates a completely different commit hash.

This happens because Git hashes the entire commit object.

The commit hash depends on:

Tree
Parent commit
Author
Author Date
Committer
Commit Date
Commit Message

Changing any of these fields creates a new object.

Even changing a timestamp by one second produces a different SHA.

Changing Dates for Multiple Commits

Now imagine changing the dates of 20 commits.

Interactive rebase becomes tedious.

You need to:

Stop at each commit.
Amend metadata.
Continue the rebase.
Resolve conflicts if they appear.

For larger repositories this quickly becomes painful.

Historically, developers used tools like:

git filter-branch

git filter-repo

to rewrite commit metadata in bulk.

These tools are powerful but can be intimidating if you don't regularly rewrite Git history.

Be Careful With Shared Branches

Before changing commit dates, remember that history rewriting affects commit hashes.

If you've already pushed commits:

git push origin main

and later rewrite dates:

git rebase -i

you'll need to force push:

git push --force-with-lease

This can disrupt teammates who already based work on the old history.

As a general rule:

Rewriting local history is usually safe.
Rewriting shared history requires caution.

A Simpler Alternative

After working with Git history rewriting for a while, I realized that changing commit dates often involves more commands than expected.

For a single commit:

git commit --amend

is manageable.

For multiple commits, interactive rebases become tedious and error-prone.

That's one of the reasons I built GitEditDate — a small tool that helps edit Git commit timestamps without manually stepping through complex rebase workflows.

Whether you use GitEditDate or standard Git commands, understanding how commit dates work makes history rewriting much less intimidating.

Final Thoughts

Changing the date of an old Git commit is possible, but Git intentionally makes it explicit.

A timestamp is not just a label attached to a commit.

It's part of the commit object itself.

Because of that:

Changing a date changes the commit hash.
Changing an old date rewrites history.
Rewriting history affects every descendant commit.

Once you understand those rules, modifying commit dates becomes much easier to reason about.

And if you've ever wondered why a simple timestamp change can trigger a cascade of new commit hashes, now you know the answer.

Why Git Has Two Dates: Author Date vs Commit Date

Alex — Fri, 10 Jul 2026 22:15:47 +0000

Most developers assume a Git commit has a single timestamp.

That's not true.

Every commit actually contains two different dates:

Author Date
Commit Date

Most of the time they are identical, which is why many developers never notice the distinction.

But once you start rebasing, cherry-picking, or rewriting history, the difference becomes important.

Understanding these two timestamps can explain some very confusing Git and GitHub behavior.

Every Commit Contains More Metadata Than You Think

Let's inspect a commit:

git show --pretty=fuller HEAD

Example output:

commit 7fd2f85...

Author: John Doe
AuthorDate: Mon Jul 1 10:00:00 2026 +0000

Commit: John Doe
CommitDate: Thu Jul 10 18:42:00 2026 +0000

Notice that Git stores two separate timestamps.

Why?

Because they represent different events.

What Is Author Date?

The Author Date represents when the change was originally created.

Imagine this workflow:

July 1   Create commit
July 5   Open pull request
July 10  Rebase branch

The code was written on July 1.

That's the Author Date.

It answers the question:

When was this work originally authored?

What Is Commit Date?

The Commit Date represents when the current commit object was created.

This is where many developers get surprised.

When Git rewrites history, it creates completely new commit objects.

For example:

git commit --amend

git rebase -i

Both operations generate new commits.

As a result, the Commit Date changes.

It answers the question:

When was this version of the commit created?

Why The Dates Become Different

Let's take a simple example.

You create a commit:

July 1

A week later you perform an interactive rebase:

July 8

Result:

AuthorDate = July 1
CommitDate = July 8

Nothing is wrong.

Git is preserving the original creation time while also recording when the rewritten commit object appeared.

Why GitHub Sometimes Looks Wrong

Many developers first encounter this distinction on GitHub.

You've probably seen something like:

Commit created: July 1
Displayed on GitHub: July 8

and wondered:

Why did GitHub change my commit date?

Usually GitHub isn't wrong.

It's simply displaying metadata that changed after a rebase, cherry-pick, or amend operation.

Understanding Author Date and Commit Date immediately explains this behavior.

Changing Commit Dates

Changing the latest commit date is relatively straightforward.

GIT_COMMITTER_DATE="$(date)" \
git commit --amend --no-edit --date "$(date)"

Changing older commits is significantly more annoying.

You typically need:

git rebase -i

followed by manual date editing and history rewriting.

This becomes painful when multiple commits are involved.

Why Commit Hashes Change

Another common surprise:

Changing only the timestamp changes the commit hash.

Many developers expect the hash to stay the same because the code didn't change.

But Git hashes the entire commit object, including metadata.

That means:

Same code
Same files
Same message
Different timestamp

results in:

Different commit hash

This is expected behavior.

When Would You Change Commit Dates?

There are legitimate reasons:

Fixing incorrect system clocks
Repository migrations
Cleaning imported history
Reconstructing chronological order
Educational demonstrations
Privacy reasons

In most cases you should avoid rewriting public history, but for personal branches and local repositories it can be useful.

Final Thoughts

Git stores two timestamps because they answer two different questions:

Author Date

When was this work originally created?

Commit Date

When was this commit object created?

Once you understand the distinction, many confusing Git and GitHub behaviors suddenly make sense.

While researching Git timestamps, I ended up building a small tool called GitEditDate that makes editing commit dates easier without manually wrestling with complex rebase commands.

Until then, I had no idea how much metadata was hiding inside a simple Git commit.