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

[Stefan Beller <sbeller@google.com>]

On Tue, Feb 7, 2017 at 3:56 AM, Cornelius Weig
<cornelius.weig@tngtech.com> wrote:
> Hi,
>
>  I was reading into the mailmap handling today and I'm a bit puzzled by the overriding behavior.
>
> This is what the documentation says about precedence (emphasis mine):
> -------------
> mailmap.file
>     The location of an augmenting mailmap file. The default mailmap, located
>     in the root of the repository, is loaded first, then the mailmap file
>     pointed to by this variable. The location of the mailmap file may be in a
>     repository subdirectory, or somewhere outside of the repository itself.
>     See git-shortlog(1) and git-blame(1).
>
> mailmap.blob
>     Like mailmap.file, but consider the value as a reference to a blob in the
>     repository. If both mailmap.file and mailmap.blob are given, both are
> !!! parsed, with _entries from mailmap.file taking precedence_. In a bare
>     repository, this defaults to HEAD:.mailmap. In a non-bare repository, it
>     defaults to empty.
> ------------
>
> So from the doc I would have expected that files always get precedence over the blob. IOW entries from .mailmap override entries from mailmap.blob. However, this is not the case.
>
> 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.

>
> So I wonder: what is the rationale behind this? I find this mixed overriding behavior hard to explain and difficult to understand.
>