keyrow's blog

Nice Git Emails

Posted: 2026-07-26 | Last Updated: 2026-07-26

1051 words | 6 minute read

Lately, I've been in a bit of a predicament regarding the email(s) I use for Git.

The Problem - Public Commit Emails

Whenever a new commit is made in a Git repository, an email is always associated with it. The issue is that when said repository is public (e.g., in the case of open-source projects), that means all emails associated with the commits in the repository are also made public.

Why is this a problem? Well, my main reasons are:

  1. A public email address increases the risk of someone attempting to break into my email account.
  2. The less stuff sent to my inbox, the better.

Apparently, scraping emails from commits is not too difficult, and it has been used as a means to spam inboxes.

Solution 1 - Built-in Alt Email

As a consequence, most if not all git hosting platforms (aka forges, TIL) have a feature where they generate an alternative email for you to use in commits in place of your actual email. In the case of GitHub, these alt emails look like 12345678+username@users.noreply.github.com. This was what I've been using up until now. However, I've recently been playing with giving a git repository two remotes:

Sure, both forges have that feature where they generate an alt email for use in commits. The issue is that these generated emails are different, and I'd rather not have two copies of the same repository with different emails used in each and having to constantly sync changes between the two.

Solution 2 - Fake Email

After investigating a little more, I noticed that the emails used for git commits aren't really used as actual email addresses. Nothing really gets sent to these commit emails, since GitHub and Forgejo will just send any relevant emails to your primary email address anyway. Furthermore, most modern open-source projects rely more on pull requests and issues than emails for communication anyway. So, I just made up an email address, and what do you know, it works! I can commit stuff just as before and things just work out since git doesn't inherently check if the email is valid or not!

Well, while digging around, I found this blog post where someone actually tried this, but ended up going back to what I referred in this post as "Solution 1". The main issue with this approach is that fake emails aren't automatically associated with a GitHub/Forgejo account, which means commits made with the fake email won't show up as any activity on the GitHub/Forgejo profile page. No contributor graphs, no green squares, not great :(

Just as an experiment, I decided to add the fake email address as a secondary email address to my forge accounts, and that did the trick! Commits were being properly associated with my account, and analytics were showing. Awesome!

The New Problem

Well, all this fake email stuff got me a bit worried. If it's so easy to just use any email I could think of as a commit email, couldn't this be easily used to impersonate others? As usual, I'm definitely not the first to realize this, and it seems like there is a feature on GitHub and Forgejo to at least allow me to differentiate my commits from arbitrary commits made with my commit email: Signed Commits.

During the signed commits setup process for GitHub, I noticed a slight issue: for commits to appear as "Verified" on GitHub, the fake email needs to be verified. Luckily for me, as I own this domain and use Cloudflare for the nameservers, I can simply utilize email routing to forward the verification email to my primary email, thus allowing me to verify the "fake" email. I can then just disable the forwarding afterwards to prevent spam. Neat! (I would like to note that email forwarding does not make the fake email a fully-functional email address because I still can't use it to send an email, only receive.)

Anyhow, after finishing up the steps given by both forges on setting up commit signing, I finally have a solution that covers almost every base:

I will, however, note that there is a caveat to this approach. There are cases where the commit email is used as a means of communication, such as for the Linux kernel. In those cases, it is indeed important to have a working email as the commit email. That said, I don't think I'll be contributing to projects of such magnitude anytime soon, so my solution works perfectly fine for all my use cases :D

(After writing this post, I just realized that another very simple solution is just to make a whole second email account specifically for use in git commits...)

Bonus JJ Section

If you've read some of my other posts regarding my blog, you may know that I've been primarily using the Jujutsu VCS instead of using git directly (just for fun). Regarding signing, this is a pretty good resource on setting up jj for commit signing.

Additionally, since I had to update the emails for all the commits of my existing repositories and signing those commits during this process, I found the following two commands to be pretty useful. (But do note that these will change the dates of the commits to the current date.)

jj metaedit --update-author -r "all() ~ root()"
jj sign -r "all() ~ root()"

And if you've already pushed some of the commits to a remote repository, just add the --ignore-immutable flag to the commands.