+8
Planned

Support for Git .mailmap file

steffel 8 years ago updated by Marc Strapetz 7 months ago 9

In some of our repositories we have commits from developers with different Name, but with same email address (short name, full name).

git already supports user name mapping by using a "mailmap" file, so only one name will be display in e.g. the git short log. SmartGit should support this, too.

mailmap support (using the git configuration) would be a great convenience. As the author of this requests states, it's quite common that there are commits from the same person, but with variations in the name. Some of my colleagues tend to use their username of the git hosting platform (e.g. GitHub, GitLab) for the user.name value (even as "@username"), which really does not help reading the history.

Since git 2.23, the "git log" command is using mailmap by default (https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.23.0.txt), which makes reading the git log more unified. 

Greetings,

just noticed that version "20.1.5 #15185" still does not obey/use the .mailmap.

Repo with several authors over the past years which used a really mixed style for names and email-adresses. Git shortlog works, unified, like it should. But I noticed SmartGit does not.

Please fix this.

Hello, is there any news on this enhancement's implementation ? The last update, 2 years ago, says it is Planned... But for when ?

Thanks in advance :-)

.mailmap should be supported since 22.1. Can you please give it a try and confirm? Then I'm going to close this topic.

Hello Marc,

Thanks for the feedback.I checked (running SmartGit 22.1.7 #19285, installed: #19259). and it does seem that .mailmap is indeed taken into consideration somehow, but not in the expected way. Let me explain.

Looking at commits authored by badfiles in repository for MantisBT (https://github.com/mantisbt/mantisbt.git) with the following mailmap:

Vladimir Shulev <badfiles(at)mail.ru> badfiles
Vladimir Shulev <badfiles(at)mail.ru> root

Some examples from the log file, demonstrating correct transformation of the commit author by Git (column 2 shows the actual, "raw" commit author, column 3 after transformation):

$ git log --format="%h|%an|%aN" --author=badfiles |sort -k 2 -u
29cc2eb3c|Vladimir Shulev|Vladimir Shulev
ceae796e3|badfiles|Vladimir Shulev
128e3af17|root|Vladimir Shulev

Looking at these commits in SmartGit, I don't see the expected name (should be Vladimir Shulev), but it appears there is some transformation applied - the "B" in the avatar I guess is coming from "badfiles" (but should be "VS")

Image 789

Image 790

I hope this helps.

Thanks, I can reproduce the problem. Following lines are not processed by SmartGit:

Vladimir Shulev <badfiles@mail.ru> badfiles
Vladimir Shulev <badfiles@mail.ru> root

However, according to the mailmap format definition:

https://git-scm.com/docs/gitmailmap

such lines are actually unexpected. The correct line would be just:

Vladimir Shulev <badfiles@mail.ru>

or:

Vladimir Shulev 1 <badfiles@mail.ru> badfiles <badfiles@mail.ru>
Vladimir Shulev 2 <badfiles@mail.ru> root <badfiles@mail.ru>

If you want to be more specific.

Thanks for pointing out the unexpected setup in our .mailmap file, I will fix that.

I confirm that SmartGit works as expected if I change to

 Vladimir Shulev <badfiles(at)mail.ru>

That being said, I would have expected SmartGit's behavior to match that of Git, and therefore be able to handle this more gracefully.

I also considered that, but the question is, what is Git's intended behavior? Is it the one defined in the documentation or the one actually present in the latest Git executable? It's likely that neither of them is perfect: the documentation might be outdated and the latest Git executable probably contains bugs. From the perspective of alternate Git implementations (such as SmartGit), the documentation is the better reference.

Your situation is not clear-cut because I don't think that the "root" username part of the Author email should always be replaced with "Vladimir Shulev". Therefore, it might be a good idea to bring this discrepancy to the attention of the Git community at https://git-scm.com/community.