On Tue, Feb 07, 2017 at 09:27:19AM -0800, Stefan Beller wrote: > > The code shows why (mailmap.c): > > err |= read_mailmap_file(map, ".mailmap", repo_abbrev); > > if (startup_info->have_repository) > > err |= read_mailmap_blob(map, git_mailmap_blob, repo_abbrev); > > err |= read_mailmap_file(map, git_mailmap_file, repo_abbrev); > > > > > > Apparently this is not an oversight, because there is an explicit > > test for this overriding behavior (t4203 'mailmap.blob overrides > > .mailmap'). > > which is blamed to 08610900 (mailmap: support reading mailmap from > blobs, 2012-12-12), > cc'ing Jeff who may remember what he was doing back then, as the > commit message doesn't discuss the implications on ordering. 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). I think the easiest way to think of it is the same as we do config. We read the files in a particular order, least-important to most-important, and apply "last one wins" (so more-important entries overwrite less-important ones). -Peff