On Tue, Feb 7, 2017 at 3:56 AM, Cornelius Weig <cornelius.w...@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. >
