Git: 'Please tell me who you are' - How to Fix It

Git stopped your first commit with Please tell me who you are because it has no name and email to stamp on the commit, and every commit must record an author. Fix it by telling Git who you are once:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Then run your commit again. That is the whole fix. The rest of this page explains what the message means, --global versus a per-repo identity, and why the error sometimes keeps coming back.

The full error

When you run git commit in a fresh install with no identity configured, Git prints something like this and refuses to create the commit:

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'you@laptop.(none)')

The error already tells you the fix. The two git config lines in the message are real commands you can copy and run (after swapping in your own name and email). The last line, unable to auto-detect email address, is Git explaining what it tried: it attempted to guess your email from your system username and hostname (you@laptop.(none)), decided that guess was not trustworthy, and gave up rather than author a commit under a fake address.

Why Git needs this

Every Git commit stores identity metadata: an author (who wrote the change) and a committer (who created the commit), each with a name and email. This is not a GitHub or remote thing, it is baked into the commit object itself, so Git blocks you locally before any push happens.

Older Git versions used to invent an identity from your OS account and hostname and let the commit through with a warning, producing commits authored by you@laptop.(none), which is useless in a shared history. Modern Git refuses instead. That is the better behavior: it makes you set a real identity once rather than polluting your history with a placeholder.

If the commit step itself is unfamiliar, my Git for beginners walkthrough covers the full first-commit flow from git init to git commit, and the staging area explainer covers the git add step that comes just before the commit Git is refusing here.

The fix, step by step

Set your name and email. Use the email you want attached to your commits (for GitHub, use an email associated with your account so the commits link back to your profile):

git config --global user.name "Ada Lovelace"
git config --global user.email "ada@example.com"

Confirm the values stuck:

git config --global user.name
git config --global user.email

Each command prints back what you just set. Now re-run your commit and it will go through:

git commit -m "Initial commit"

There is nothing to install and nothing to restart. The config takes effect immediately for the next commit. Setting your identity is part of the same one-time machine setup you do when you set up Git for a new project, so doing it with --global here means you will not see this error again on the next repo.

With the identity in place and the commit landing, the natural next thing to firm up is good commit message conventions so that history reads cleanly from the start.

--global versus per-repo: which to use

The --global flag writes the identity to ~/.gitconfig, so it applies to every repository on your machine that does not override it. Omit --global (run the command inside a repo) and Git writes to that repo's .git/config, applying only there. A per-repo identity always wins over the global one for that repository.

For most people the answer is --global: set it once and forget it. The common reason to set a per-repo identity is keeping work and personal commits on different email addresses, and using a different identity is a common reason to pick an SSH vs HTTPS remote too, since SSH keys are tied to whichever account you authenticate as. Set the global identity to whichever you use most, then override it per-repo in the other set of projects:

# inside the work repository, no --global:
git config user.email "ada@company.com"
git config user.name "Ada Lovelace"

That writes to .git/config for just that project and leaves your global identity alone.

When the error keeps coming back

You set both values and the commit still fails, or the next repo you clone throws the same error. A few causes:

You set it per-repo in a different folder. If you ran the config without --global while inside some other project, you only fixed that one repo. The next fresh repo has no identity again. Re-run with --global so it covers everything.

You set the wrong scope or there is a typo in the key. Git config keys are user.name and user.email, both lowercase, with a dot. User.Name or username will not work. Check what Git actually sees with the all-scopes listing:

git config --list --show-origin | grep user

The --show-origin part prints which file each value came from, so you can see whether your user.email is in ~/.gitconfig, in .git/config, or missing entirely.

A previous commit was already authored badly and you want to fix it. Setting the identity now only affects future commits. If you already committed under you@laptop.(none), the bad author is baked into that commit. To redo just the most recent one, amend it:

git commit --amend --reset-author --no-edit

--reset-author restamps the commit with your current (now-correct) identity, which is one of the cases where amending the last commit is exactly the right tool. Rewriting many old commits is a history-rewrite job with the same caution that applies when you strip a secret out of Git history: it changes commit hashes and forces everyone else to re-sync.

Related first-time-setup errors

This message usually shows up during your first few minutes with Git, alongside a small family of similar setup errors. If you are working through initial setup, these are the neighbors you are most likely to hit next:

• fatal: not a git repository when you run a Git command outside an initialized folder.
• The current branch has no upstream branch on your first git push.
• Permission denied (publickey) if you are using an SSH remote without a key registered. My guide to adding an SSH key to GitHub covers that setup end to end.

Once your identity is set and your first commit lands, the beginner branching guide is a good next read.