On 02/07/2017 08:28 PM, Jeff King wrote: > > 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@xxxxxxxx: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@xxxxxxxx'. 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.