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

From: Jeff King <peff@peff.net>
Date: Feb 7, 2017, 19:28 UTC
Message-ID: <20170207192801.qoncjaqjpn3axpyn@sigill.intra.peff.net>
In-Reply-To: <CAGZ79kZ=ikbYpuK6E=ui1ju=bRavcVcxb3AA_dvb2Jp6cRNmJQ@mail.gmail.com>

On Tue, Feb 07, 2017 at 09:27:19AM -0800, Stefan Beller wrote:

Show 15 quoted lines

> > 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