The short answer
GitLab does not have one email setting. It has several, and they control different things: the address you sign in with, the address shown on your public profile, and the address attached to commits you author. Retiring an address safely means checking each surface, because changing one does not automatically clean up the others.
GitLab’s primary email is the default for login, commits and notifications; changing it keeps the former primary address as a secondary address. Source
That single sentence already creates a trap. If you change your primary email to a new address, the old one does not disappear from your account. It stays attached as a secondary address, which means it can still be associated with your identity on GitLab even after you stop using it for sign-in.
Three surfaces, three different settings
| Surface | What it controls | Why it matters when retiring an email |
|---|---|---|
| Primary email | Default for login, commits and notifications | Changing it demotes the old address to secondary rather than removing it |
| Public email | The address shown on your public profile | A separate field; it can display an address that is not your login address |
| Commit email | The address attached to commits you author | Offers a private-email option, but local Git configuration also matters |
The practical lesson is that “make my profile private” and “stop using this address” are not the same operation. Each row above needs its own check.
Step 1: Decide what the public profile should show
The Public email field is its own setting. It chooses which address, if any, appears on your public profile.
The Public email field chooses an address shown on the public profile and is a separate setting. Source
Because it is separate, changing your primary login address does not by itself change what visitors see on your profile. Check the Public email field directly and decide whether the address there is one you are comfortable displaying. If you are retiring an address, this is the first place to look, because it is the most visible surface.
Step 2: Change the primary address deliberately
If the goal is to stop signing in with an old address, change the primary email. Be aware of what that does: the former primary address becomes a secondary address rather than being deleted.
GitLab’s primary email is the default for login, commits and notifications; changing it keeps the former primary address as a secondary address. Source
So plan for a second decision. After the change, review the secondary addresses on the account and decide whether the old one should remain attached. The approved sources here describe the demotion behavior but do not spell out every removal path, so treat the exact steps for removing a secondary address as something to confirm in your own account settings rather than assume.
Step 3: Check what your commits expose
Commit email is the surface people most often overlook, because it is tied to code history rather than to a profile page. GitLab’s commit email selection includes a private-email option.
GitLab offers Use a private email in the Commit email selection; a local Git configuration must also be considered for local commits. Source
That option covers commits made through GitLab, but not everything. A local Git configuration on your machine can also determine the address recorded in commits you create locally, so the GitLab setting alone may not cover your whole history going forward. If commit privacy matters to you, check both the GitLab commit email setting and your local Git configuration.
The historical-commit limit
This is the part that deserves the most caution. The approved facts describe current settings, not retroactive rewriting. Nothing in the supplied sources establishes that changing your commit email setting, or making your profile private, removes an address already recorded in past commits.
Treat historical exposure as a separate question from current configuration:
- Current settings control what happens to new activity.
- Past commits were authored under whatever configuration existed at the time.
- Profile visibility is a display setting, not a claim about what is stored or recorded elsewhere.
If an old address in commit history is the real concern, verify that surface directly rather than assuming a settings change reached backward. The sources here do not document a retroactive cleanup mechanism, so do not plan around one.
A verification checklist
Work through these in order, and record what you actually observe in your account rather than what you expect:
- Public profile. Open your profile as a visitor would and note which address, if any, is displayed. Then check the Public email field and confirm it matches your intent.
- Primary email. Confirm which address is currently primary and which are secondary. If you change the primary, re-check the list afterward and note that the old address now sits among the secondary addresses.
- Commit email setting. Confirm which option is selected for commits made through GitLab.
- Local Git configuration. Check the email configured on any machine where you commit locally, since that can differ from the GitLab setting.
- Historical commits. Look at commits you authored in the past and note which address appears. Do not assume a settings change altered them.
A useful habit is to repeat steps 1 through 3 after any change, because these settings are independent and a change in one does not confirm a change in another.
Where this fits in a wider cleanup
This guide is deliberately narrow: it covers the separation between GitLab’s public profile address, login address and commit address. If your broader task is finding which accounts are tied to an email address in the first place, that is a different job. A username or email lookup can surface public matches as leads, but public matches are leads rather than proof of ownership, and a lookup is not a complete account inventory. For that next step, see the related guide on finding accounts by an email address.
If you want to check where a username appears across platforms as part of the same review, TraceSeek covers 3,000+ platforms and offers a free first scan that the product describes as taking 20-30 seconds. Those are product statements rather than independent measurements, and a scan result should be treated as a starting point for verification, not as confirmation of identity.
What to avoid
- Do not assume that hiding your public profile removes an address from commit history.
- Do not assume that changing your primary email deletes the old one; it becomes a secondary address.
- Do not rely on the GitLab commit email setting alone if you also commit locally.
- Do not treat a public match between a username and an email as proof that both belong to the same person.
FAQ
Does changing my GitLab primary email remove the old address?
No, based on the approved facts. The former primary address is kept as a secondary address, so the old address remains attached to the account and needs a separate decision.
Is the Public email field the same as my login email?
They are separate settings. The Public email field chooses an address shown on your public profile, while the primary email is the default for login, commits and notifications.
If I set a private commit email, are my old commits updated?
The supplied sources do not establish any retroactive change to past commits. Check historical commits directly rather than assuming the setting reached backward.
Do I need to change anything outside GitLab for commit privacy?
Possibly. A local Git configuration also affects commits you create locally, so the GitLab setting alone may not cover everything.