DEV Community

Alex
Alex

Posted on

How to Change the Date of an Old Git Commit

#beginners #cli #git #tutorial

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
Enter fullscreen mode Exit fullscreen mode

Example:

AuthorDate: Mon Jul 1 10:00:00 2026 +0000
CommitDate: Mon Jul 1 10:00:00 2026 +0000
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Git will open an editor:

pick A
pick B
pick C
pick D
Enter fullscreen mode Exit fullscreen mode

Change the target commit:

pick A
edit B
pick C
pick D
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

Continue the rebase:

git rebase --continue
Enter fullscreen mode Exit fullscreen mode

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:

  1. Stop at each commit.
  2. Amend metadata.
  3. Continue the rebase.
  4. Resolve conflicts if they appear.

For larger repositories this quickly becomes painful.

Historically, developers used tools like:

git filter-branch
Enter fullscreen mode Exit fullscreen mode

or

git filter-repo
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

and later rewrite dates:

git rebase -i
Enter fullscreen mode Exit fullscreen mode

you'll need to force push:

git push --force-with-lease
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)