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

[Jeff King <peff@peff.net>]

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