Re: [RFC] mailmap.blob overrides default .mailmap

From: Cornelius Weig <cornelius.weig@tngtech.com>
Date: Feb 7, 2017, 22:45 UTC
Message-ID: <53836bcd-1d4d-13fb-a523-1258017d19c9@tngtech.com>
In-Reply-To: <20170207192801.qoncjaqjpn3axpyn@sigill.intra.peff.net>

On 02/07/2017 08:28 PM, Jeff King wrote:

Show 11 quoted lines

> 
> I think it was mostly that I had to define _some_ order. This made sense
> to me as similar to things like attributes or excludes, where we prefer
> clone-specific data over in-history data (so .git/info/attributes takes
> precedence over .gitattributes).
> 
> So any mailmap.* would take precedence over the in-tree .mailmap file.
> And then between mailmap.file and mailmap.blob, the "blob" form is
> more "in-tree" than the "file" form (especially because we turn it on by
> default in bare repos, so it really is identical to the in-tree form
> there).

So the clone-specific data wins over in-history makes perfect sense to me. Therefore, mailmap.file should win over mailmap.blob, agreed.

On the other hand, a checked-in .mailmap file and a mailmap-blob are both as in-history as the other to me. Now consider the following settings:

$ git config --unset mailmap.file $ git config mailmap.blob HEAD:.mailmap $ sed -i 's:peff@peff.com:no-valid-address:' .mailmap $ git log -1 --author 'Jeff King'

So with the .mailmap being dirty, which address would one expect to be printed? I would expect 'no-valid-address', but it's 'peff@peff.com'.

Even though the .mailmap file is more visible and also closer to the user, the mailmap.blob wins over it. I find that somewhat counter-intuitive. Of course, setting `git config mailmap.file .mailmap`, would do the trick.