.mailmap in Bitbucket does not display corrected name

Hi @Charlie Misonne, it's supported. The Git resources page in the same 9.4 space you linked says so outright, that .mailmap is useful "in Bitbucket Data Center repositories, to map multiple commit identities to the one Bitbucket user": https://confluence.atlassian.com/spaces/BITBUCKETSERVER094/pages/1489801691/Git+resources

Your mapping line is fine too, I dropped it into a throwaway repo and it maps. Bitbucket stores your repo bare though, and in a bare repo mailmap.blob defaults to HEAD:.mailmap, so the file the server reads is the one committed at the repo root on the default branch. shortlog reads the copy in your working tree. That's why it corrects whether or not the file is tracked, and why with nothing on HEAD the server still gets the raw author email, which is both of the things you're seeing: raw name, and an address no account holds.

So commit it at the repo root there and push it. The mapping gets applied at read time, so the commit you already pushed picks it up, no rewrite. To check whether that's your problem, from the clone you have: git fetch, then git show origin/main:.mailmap, swapping in whatever your default branch is. If that errors with "exists on disk, but not in origin/main", that's the whole thing. If it prints your mapping, placement is fine and the email is where I'd look next.

Careful with the local checks. check-mailmap, git log --format=%aN and even plain git log all correct off an untracked file, so none of them tell you whether it's committed.

On the email, BSERV-3235 is Bryan Turner saying a .mailmap is how you make user linking kick in when the commit email doesn't match the account, on the commit list, the single commit page and blame. Linking is on the address alone, so the canonical address on the left of your mapping has to be one a Bitbucket account holds. Yours reads example.int while the line above it says example.com. Probably an artefact of the anonymisation, but if the real file carries that mismatch you'd get the corrected name and still no link.

The hook reads the mailmap the same way, from that branch as it stood before your push, so if the file isn't already there it has no mapping to use, and one arriving in the same push can't help that push. Atlassian's KB on bypassing that hook has you push the file first and enable the hook after.

The git side of this I've reproduced myself. The Bitbucket side is that doc plus the ticket, and I couldn't find anything saying whether those screens rewrite the displayed name as well as the link, so I'd confirm that half on your own instance.