[PATCH 0/3] Add support for git's mailmap.

[smithj4 at bnl.gov (Jason A. Smith)]

Hi John,

I always thought that by going through the trouble of collecting the 
duplicate email addresses and creating the .mailmap file that you wanted 
this coalescing behavior.

Personally, I don't really want to have to remember everyone's old email 
address and variation of their name that they might have used several 
years ago to push a commit. I don't really care what email & name they 
used a long time ago, I am more interested in just knowing who made the 
commit, which is why the .mailmap coalesces all of their old identities 
into their current one for display.

If people don't need or want this coalescing behavior and want to see 
each individual identity then they don't need to make the .mailmap file 
to begin with.

Just my opinion on .mailmap.

~Jason


On 10/28/2017 07:36 AM, John Keeping wrote:
> 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
> directions).
> 
> 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
> sites.
>