[PATCH 0/3] Add support for git's mailmap.
john at keeping.me.uk
Sat Oct 28 13:36:46 CEST 2017
On Tue, Oct 24, 2017 at 10:55:21AM -0400, Jason A. Smith wrote:
> Seeing a lot of recent activity I checked the upstream and see that the
> patch I first submitted over a year ago has still not been merged. I
> already had to rebase it once several months ago to fix conflicts, I
> don't want to have to do that again. Is there something wrong with this
> patch? Please let me know so I can fix it.
I've taken another look at this patch and one thing that stands out is
that we end up inserting code to map users in a lot of different places.
I haven't audited the code, but after the final patch, is there anywhere
that calls cgit_parse_commit() and doesn't go on to map the users?
(Even if not all callers do map the user, can we push cgit_map_user()
into cgit_parse_commit() and use a flag parameter to enable it?)
But I think that points to a deeper philosophical question of whether we
should be mapping the user in all cases (and I suspect this is why the
patch has sat on the list for so long - there are arguments in both
As I understand it, mailmap was originally introduced so that
git-shortlog would coalesce commits from the same author but with
different email addresses. When using the git command, mailmap is
enabled by default for git-shortlog and git-blame but not for git-log,
git-show, and other commands that print commits.
Extending this to CGit, it seems that there's a clear argument for
enabling mailmap in ui-stats and possibly the new ui-blame, but when we
print a commit in ui-commit or ui-log is it always correct to apply the
mailmap or should we show the commit headers as-is?
It would be interesting to know what others on the list think about
this. If there isn't a consensus then we may want a new config option
to allow this to be enabled according to the preferences of individual
More information about the CGit