Support local (repository level) and organisation-wide mailmap displays from within GitHub

[GrayedFox]

🏷️ Discussion Type

Product Feedback

Body

Git supports a .mailmap file that maps the names and email addresses recorded in commits to one canonical identity, and git log, git shortlog, and git blame all honour it. GitHub ignores it, so everywhere GitHub shows a commit it uses the raw identity stored in the commit, or the GitHub username linked to that email, rather than the identity the repository or organisation has chosen.

This request asks GitHub to:

1. Honour a repository's .mailmap when displaying commit authors and committers
2. Support an organisation-wide mailmap that applies to every repository in the organisation, with each repository's own .mailmap taking precedence

It builds on #22518, which has asked for repository-level support since 2020.

Problem

In a large organisation the same person often appears under several identities:

• Their GitHub username, which GitHub shows instead of their name for any email linked to their account
• Their GitHub noreply address, used because they keep Block command line pushes that expose my email enabled
• Their work email, a personal email, or a previous employer's email

Commit lists, blame, and pull request commit tabs end up showing a mix of usernames and addresses that colleagues cannot match to a real person. People who keep their email private are worse off: the only way to show their work identity on their commits is to turn off the push protection and publish their address in every commit.

A .mailmap already solves this locally. Keeping one per repository does not scale, though: an organisation with hundreds of repositories has to commit the same file to each of them and keep every copy in sync.

Proposal

• Repository mailmap: GitHub reads .mailmap from the root of the default branch, using the same format and matching rules as Git.
• Organisation mailmap: organisation owners can define one mailmap that applies to all of the organisation's repositories, for example a .mailmap at the root of the organisation's .github or .github-private repository.
• Display: wherever GitHub shows a commit's author or committer, it shows the mapped name and email instead of the raw values.

Acceptance criteria

• GitHub reads the .mailmap at the root of a repository's default branch and applies it to every commit displayed in that repository
• Organisation owners can define an organisation-wide mailmap that GitHub applies to every repository in the organisation
• The organisation-wide mailmap has lower precedence than a repository's .mailmap: when both map the same name or email, the repository entry wins, and organisation entries only apply to identities the repository file does not map
• Wherever GitHub displays a commit author or committer, it replaces the raw email(s) and username(s) with the mapped author name and email, including:
  • Commit lists and commit detail pages
  • Blame and file history views
  • The commits tab of pull requests
  • Contributor lists
• Given the mapping Mona Lisa <mona@example.com> <583231+octocat@users.noreply.github.com>, a commit authored with 583231+octocat@users.noreply.github.com that GitHub currently shows as "octocat authored" shows as "Mona Lisa authored", with mona@example.com wherever an email is shown

Considerations

• Commit objects are never rewritten: a mailmap changes only what GitHub displays, never a commit's SHA
• Signature verification keeps checking the raw committer email recorded in the commit, so a mapping can never turn an unverified commit into a verified one
• If the organisation mailmap is stored privately, its mapped names and emails should not be shown on the organisation's public repositories to viewers outside the organisation

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐