Changed Git email but old commits still show the old author: check the right layer

By ON Lab · Sources checked November 8, 2026

Changing Git's user.email affects newly created commits; it does not edit the author email stored in old commits. Inspect the existing commit and the identity Git would use now as separate evidence. If the problem is GitHub profile attribution, account email association is another check. Do not start with a history rewrite just because a configuration value changed successfully.

The reported problem

A GitHub Community reader asked why their commit appeared under an unknown identity after using a different local email. The discussion includes suggestions to rewrite history and a later report that repository restrictions prevented the attempted approach. Those replies are user proposals, not authority to change a shared repository.

The current GitHub documentation separates configuration for future commits from previously created commit metadata. Our local comparison demonstrates that distinction before involving any account or remote. It does not test GitHub's contribution graph or validate a particular user's email address.

Read the old commit and current identity separately

git log -1 --format='%h %an <%ae>'
git config --show-origin --get user.email
git config --show-origin --get user.name
git var GIT_AUTHOR_IDENT

The log command reads the author stored in the selected commit. The configuration queries show values and their source files. The author identity command shows the author identity Git would use in the current context, including the timestamp. Preserve the relevant values privately; avoid posting personal email addresses unnecessarily in a public issue.

If these disagree, that is not automatically a broken configuration. An old commit can correctly retain the old author while the next commit uses the new configuration. Also distinguish author metadata from committer metadata when examining a commit created by another workflow.

Choose the intended configuration scope

A repository-local setting applies to that repository and can override a global setting. A global change affects the default for other repositories on the computer. If work and personal repositories need different identities, inspect the effective value inside the exact repository before deciding which scope to edit.

git config --local user.name "Your chosen author name"
git config --local user.email "YOUR_INTENDED_EMAIL"
git config --show-origin --get user.email
git var GIT_AUTHOR_IDENT

These are configuration mutations, not read-only diagnostics. Replace the placeholders only after choosing the intended identity and scope. The example does not add or verify an email address on GitHub and does not change the account used to access a remote. Git's author name is also distinct from a GitHub username.

What our two-commit test showed

We created a disposable local repository using an example.invalid email address and committed a small text file. Then we changed only that repository's author name and email. The existing log entry still showed the original author, while Git's current author identity showed the new value.

After changing the text file and creating a second commit, the two-entry log showed the new author on the new commit and the old author on the first. No earlier commit was rewritten. We did not add a remote, push a commit, authenticate, or modify global Git configuration.

This test establishes what local commit creation does. It does not establish whether a real email is verified, whether an organization permits it, whether a contribution qualifies for a graph, or which account a credential helper will use.

For GitHub attribution, check the account layer

The official email guide explains how GitHub associates command-line commits with an account through the email address. Read that guide's current account and privacy requirements when choosing an address. If using a GitHub-provided no-reply address, use the actual address shown for your account rather than inventing its format.

Adding or verifying an account email is a separate account action. A local configuration command's success is not evidence that the address was added, verified, or associated with your profile. Reopen the actual account setting when you make an authorized change; do not infer the result from a terminal value.

If the symptom is a push permission error, stop treating the author string as proof of authentication. Record the exact error and the access method. This guide does not replace credentials, create tokens, or broaden repository access.

Decide what to do about existing commits

First determine whether the goal is correct future metadata, account attribution of existing metadata, or a deliberate historical correction. Those are different tasks. The first may need only a reviewed local configuration change; the others need their own evidence and permissions.

Rewriting old commits changes repository history and can affect collaborators. The commands in a community answer should not become a default force-push recipe. Use the repository's agreed process for any historical correction and preserve a recovery path. This article intentionally does not execute or prescribe a history rewrite.

Confirm success at the relevant layer

For a future-identity correction, inspect the next intended commit's actual author metadata. For account attribution, verify the actual account result separately. For access, verify the authorized remote operation and its outcome. Avoid calling all three fixed because user.email prints the expected text.

Sources checked November 8, 2026. Effective local identity and two-commit metadata behavior were reproduced with invalid example addresses. GitHub attribution, email verification, authentication, pushes, and history rewrites were not performed.