skip to content

When you run git commit --amend, what happens to the author and committer fields?

level: middleimportance: nice to knowfreq 30%

answer

  1. a commit stores two identities
  2. one is preserved, one is refreshed
  3. this is why the hash always moves
  4. git log hides one of them by default
  5. a flag exists to re-attribute the commit

basics

~20 s

Amend preserves the original author name, email and author date, but sets the committer to your current identity with the timestamp of the amend. That refreshed committer line is why the SHA changes even when the tree and message are unchanged.

solid answer

~40 s

A Git commit records two identities. The **author** is who wrote the change; the **committer** is who put it into the repository. `git commit --amend` copies the author fields from the commit it replaces — name, email and author date — and writes the committer fields from your current `user.name` and `user.email` with the current time. That is deliberate: it preserves attribution when you tidy someone else's patch, while recording who actually performed the rewrite. It also means the object's bytes always differ from the original, so the SHA always changes. `git log` shows the author date by default, so an amended commit can look untouched; `git log --pretty=fuller` shows both pairs. Use `--reset-author` if you want the author reset to you, or `--date=<date>` to set the author date explicitly.

code

console · 6 lines
console
$ git commit --amend --no-edit
$ git log -1 --pretty=fuller
Author:     Ada <[email protected]>
AuthorDate: Mon Mar 3 09:12:44 2025 +0100
Commit:     Grace <[email protected]>
CommitDate: Tue Mar 4 16:40:02 2025 +0100

go deeper

for a junior

Remember a commit stores an author and a committer, and that amending keeps the author while recording you as the committer with a fresh timestamp.

for a middle

Explain why the refreshed committer line guarantees a new SHA, and name --reset-author as the way to re-attribute a commit made with the wrong email.

for a senior

Discuss what these fields are and are not good for in an audit: durable authorship versus last-rewriter, both free text that any client can set, so neither proves identity on its own.

for a principal

Own the policy question of how provenance is actually established in your history, and the tradeoff between rewriting for clean attribution and leaving history untouched.

## Two identities in one commit Every commit object carries an `author` line and a `committer` line, each with a name, an email address and a timestamp with timezone offset. They exist because Git grew up around emailed patches: someone writes a change (author), someone else applies it to the canonical repository (committer). In everyday work both are you, which is why many people never notice the distinction — until a rewrite makes them diverge. ## What amend does to each - **Author**: copied verbatim from the commit being replaced. Name, email and author date all survive. - **Committer**: taken fresh from your configured `user.name` and `user.email`, with the current timestamp. So after amending a colleague's commit, the log still credits them, while the committer line records that you touched it. The same rule applies to rebase and cherry-pick, which is why a rebased branch shows old author dates and brand-new committer dates. ## Why this guarantees a new SHA A commit's id is the hash of its serialized content, and the committer line is part of that content. Since the committer timestamp is refreshed on every amend, even `git commit --amend --no-edit` with an identical index yields a different id. If you have ever wondered why the SHA changed when "nothing changed", this is the answer. ## Seeing both pairs By default `git log` prints only the author. To see all four values use `git log --pretty=fuller`, which prints `Author`, `AuthorDate`, `Commit` and `CommitDate`. With a custom format, `%an`/`%ae`/`%ad` are the author fields and `%cn`/`%ce`/`%cd` the committer ones. This matters when a history looks chronologically impossible in one view and fine in another: sorting in `git log` is by graph topology and date options, and the two dates can disagree by months on a rebased branch. ## Overriding the defaults - `git commit --amend --reset-author` sets the author to the current committer identity and resets the author date to now. This is the fix when you committed with the wrong `user.email` — for example a personal address on a work repository — and want the commit re-attributed to you correctly. - `git commit --amend --author="Name <email>"` sets an explicit author, which is how you preserve credit when you rebuild someone else's patch by hand. - `git commit --amend --date=<date>` sets the **author** date only; it does not touch the committer date. - The environment variables `GIT_AUTHOR_NAME`, `GIT_AUTHOR_EMAIL`, `GIT_AUTHOR_DATE`, `GIT_COMMITTER_NAME`, `GIT_COMMITTER_EMAIL` and `GIT_COMMITTER_DATE` override the configured values for a single invocation, and are the only supported way to set the committer date directly. ## Practical consequences The wrong-email case is the one interviewers actually probe. A developer commits with an unconfigured or personal identity, notices, fixes `user.email`, and amends — and is then surprised that the log still shows the old address. The plain amend preserved the author on purpose; `--reset-author` is what they needed. If the mistake spans several commits, the same reset has to be applied by each rewritten commit during an interactive rebase rather than by a single amend. The second consequence is auditing. Because the committer identity is refreshed by every rewrite, it is a rough record of who last handled a commit, while the author identity is a durable record of who wrote it. Neither is authenticated by itself — both are free-text fields any client can set — so identity claims in a commit are a convention, not a security control. ## Interview framing Say that Git stores two identities, that amend keeps the author and refreshes the committer, and connect that to the SHA changing. Mentioning `--reset-author` as the fix for a wrong-email commit shows you have hit the case in practice.

  • You committed with the wrong user.email. Does a plain git commit --amend fix the attribution?
    No. Amend preserves the author fields, so the wrong address survives even though your config is now correct. Fix your `user.email`, then run `git commit --amend --reset-author`, which sets the author to your current identity and resets the author date. For several commits you need an interactive rebase applying the same reset to each.
  • Which git log output shows both the author and the committer?
    `git log --pretty=fuller` prints Author, AuthorDate, Commit and CommitDate for each entry. With a custom format string, `%an`, `%ae` and `%ad` give the author fields and `%cn`, `%ce` and `%cd` the committer ones. The default log format shows only the author, which is why rebased branches often look like nothing was rewritten.

saying these in an interview costs you the question

  • Thinks amend replaces the author with the current user
  • Assumes there is only one identity on a commit
  • Believes --date changes the committer date
  • Says the SHA can stay the same if the tree is unchanged
  • Treats the author email as an authenticated identity

context

resolving links…