{"thread":{"id":"45070","subject":"[RFC] mailmap.blob overrides default .mailmap","startedAt":"2017-02-07T11:56:09Z","lastAt":"2017-02-08T19:51:04Z","messageCount":5,"participants":["Cornelius Weig","Stefan Beller","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"310980","messageId":"77c0182b-8c4f-9727-f56f-d8e2bad8146d@tngtech.com","threadId":"45070","inReplyTo":null,"subject":"[RFC] mailmap.blob overrides default .mailmap","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-02-07T11:56:00Z","receivedAt":"2017-02-07T11:56:09Z","isPatch":false,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"Hi,\n\n I was reading into the mailmap handling today and I'm a bit puzzled by the overriding behavior.\n\nThis is what the documentation says about precedence (emphasis mine):\n-------------\nmailmap.file\n    The location of an augmenting mailmap file. The default mailmap, located\n    in the root of the repository, is loaded first, then the mailmap file\n    pointed to by this variable. The location of the mailmap file may be in a\n    repository subdirectory, or somewhere outside of the repository itself.\n    See git-shortlog(1) and git-blame(1).\n\nmailmap.blob\n    Like mailmap.file, but consider the value as a reference to a blob in the\n    repository. If both mailmap.file and mailmap.blob are given, both are\n!!! parsed, with _entries from mailmap.file taking precedence_. In a bare\n    repository, this defaults to HEAD:.mailmap. In a non-bare repository, it\n    defaults to empty.\n------------\n\nSo 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.\n\nThe code shows why (mailmap.c):\n\terr |= read_mailmap_file(map, \".mailmap\", repo_abbrev);\n\tif (startup_info->have_repository)\n\t\terr |= read_mailmap_blob(map, git_mailmap_blob, repo_abbrev);\n\terr |= read_mailmap_file(map, git_mailmap_file, repo_abbrev);\n\n\nApparently this is not an oversight, because there is an explicit test for this overriding behavior (t4203 'mailmap.blob overrides .mailmap').\n\nSo I wonder: what is the rationale behind this? I find this mixed overriding behavior hard to explain and difficult to understand.\n\n"},{"id":"310991","messageId":"CAGZ79kZ=ikbYpuK6E=ui1ju=bRavcVcxb3AA_dvb2Jp6cRNmJQ@mail.gmail.com","threadId":"45070","inReplyTo":"77c0182b-8c4f-9727-f56f-d8e2bad8146d@tngtech.com","subject":"Re: [RFC] mailmap.blob overrides default .mailmap","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-02-07T17:27:19Z","receivedAt":"2017-02-07T17:27:25Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Feb 7, 2017 at 3:56 AM, Cornelius Weig\n<cornelius.weig@tngtech.com> wrote:\n> Hi,\n>\n>  I was reading into the mailmap handling today and I'm a bit puzzled by the overriding behavior.\n>\n> This is what the documentation says about precedence (emphasis mine):\n> -------------\n> mailmap.file\n>     The location of an augmenting mailmap file. The default mailmap, located\n>     in the root of the repository, is loaded first, then the mailmap file\n>     pointed to by this variable. The location of the mailmap file may be in a\n>     repository subdirectory, or somewhere outside of the repository itself.\n>     See git-shortlog(1) and git-blame(1).\n>\n> mailmap.blob\n>     Like mailmap.file, but consider the value as a reference to a blob in the\n>     repository. If both mailmap.file and mailmap.blob are given, both are\n> !!! parsed, with _entries from mailmap.file taking precedence_. In a bare\n>     repository, this defaults to HEAD:.mailmap. In a non-bare repository, it\n>     defaults to empty.\n> ------------\n>\n> 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.\n>\n> The code shows why (mailmap.c):\n>         err |= read_mailmap_file(map, \".mailmap\", repo_abbrev);\n>         if (startup_info->have_repository)\n>                 err |= read_mailmap_blob(map, git_mailmap_blob, repo_abbrev);\n>         err |= read_mailmap_file(map, git_mailmap_file, repo_abbrev);\n>\n>\n> Apparently this is not an oversight, because there is an explicit test for this overriding behavior (t4203 'mailmap.blob overrides .mailmap').\n\nwhich is blamed to 08610900 (mailmap: support reading mailmap from\nblobs, 2012-12-12),\ncc'ing Jeff who may remember what he was doing back then, as the\ncommit message doesn't discuss the implications on ordering.\n\n>\n> So I wonder: what is the rationale behind this? I find this mixed overriding behavior hard to explain and difficult to understand.\n>\n"},{"id":"310996","messageId":"20170207192801.qoncjaqjpn3axpyn@sigill.intra.peff.net","threadId":"45070","inReplyTo":"CAGZ79kZ=ikbYpuK6E=ui1ju=bRavcVcxb3AA_dvb2Jp6cRNmJQ@mail.gmail.com","subject":"Re: [RFC] mailmap.blob overrides default .mailmap","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-07T19:28:01Z","receivedAt":"2017-02-07T19:35:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 07, 2017 at 09:27:19AM -0800, Stefan Beller wrote:\n\n> > The code shows why (mailmap.c):\n> >         err |= read_mailmap_file(map, \".mailmap\", repo_abbrev);\n> >         if (startup_info->have_repository)\n> >                 err |= read_mailmap_blob(map, git_mailmap_blob, repo_abbrev);\n> >         err |= read_mailmap_file(map, git_mailmap_file, repo_abbrev);\n> >\n> >\n> > Apparently this is not an oversight, because there is an explicit\n> > test for this overriding behavior (t4203 'mailmap.blob overrides\n> > .mailmap').\n> \n> which is blamed to 08610900 (mailmap: support reading mailmap from\n> blobs, 2012-12-12),\n> cc'ing Jeff who may remember what he was doing back then, as the\n> commit message doesn't discuss the implications on ordering.\n\nI think it was mostly that I had to define _some_ order. This made sense\nto me as similar to things like attributes or excludes, where we prefer\nclone-specific data over in-history data (so .git/info/attributes takes\nprecedence over .gitattributes).\n\nSo any mailmap.* would take precedence over the in-tree .mailmap file.\nAnd then between mailmap.file and mailmap.blob, the \"blob\" form is\nmore \"in-tree\" than the \"file\" form (especially because we turn it on by\ndefault in bare repos, so it really is identical to the in-tree form\nthere).\n\nI think the easiest way to think of it is the same as we do config. We\nread the files in a particular order, least-important to most-important,\nand apply \"last one wins\" (so more-important entries overwrite\nless-important ones).\n\n-Peff\n"},{"id":"311013","messageId":"53836bcd-1d4d-13fb-a523-1258017d19c9@tngtech.com","threadId":"45070","inReplyTo":"20170207192801.qoncjaqjpn3axpyn@sigill.intra.peff.net","subject":"Re: [RFC] mailmap.blob overrides default .mailmap","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-02-07T22:45:31Z","receivedAt":"2017-02-07T22:46:48Z","isPatch":false,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"On 02/07/2017 08:28 PM, Jeff King wrote:\n> \n> I think it was mostly that I had to define _some_ order. This made sense\n> to me as similar to things like attributes or excludes, where we prefer\n> clone-specific data over in-history data (so .git/info/attributes takes\n> precedence over .gitattributes).\n> \n> So any mailmap.* would take precedence over the in-tree .mailmap file.\n> And then between mailmap.file and mailmap.blob, the \"blob\" form is\n> more \"in-tree\" than the \"file\" form (especially because we turn it on by\n> default in bare repos, so it really is identical to the in-tree form\n> there).\n\nSo the clone-specific data wins over in-history makes perfect sense to me. Therefore, mailmap.file should win over mailmap.blob, agreed.\n\nOn the other hand, a checked-in .mailmap file and a mailmap-blob are both as in-history as the other to me. Now consider the following settings:\n\n$ git config --unset mailmap.file\n$ git config mailmap.blob HEAD:.mailmap\n$ sed -i 's:peff@peff.com:no-valid-address:' .mailmap\n$ git log -1 --author 'Jeff King'\n\nSo with the .mailmap being dirty, which address would one expect to be printed? I would expect 'no-valid-address', but it's 'peff@peff.com'.\n\nEven though the .mailmap file is more visible and also closer to the user, the mailmap.blob wins over it. I find that somewhat counter-intuitive. Of course, setting `git config mailmap.file .mailmap`, would do the trick.\n\n"},{"id":"311081","messageId":"20170208195022.6kqpgit3lkvskxta@sigill.intra.peff.net","threadId":"45070","inReplyTo":"53836bcd-1d4d-13fb-a523-1258017d19c9@tngtech.com","subject":"Re: [RFC] mailmap.blob overrides default .mailmap","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-08T19:50:22Z","receivedAt":"2017-02-08T19:51:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 07, 2017 at 11:45:31PM +0100, Cornelius Weig wrote:\n\n> On the other hand, a checked-in .mailmap file and a mailmap-blob are\n> both as in-history as the other to me. Now consider the following\n> settings:\n\nI think it depends how you use them. You could point mailmap.blob to\nsome other ref entirely (even one that you fetched from another\nrepository).\n\nI'd expect normal use to point it to HEAD:.mailmap, though (and that was\ncertainly the use case I wrote it for). On the other hand, the point of\npointing it to that particular blob is that it works even when you\n_don't_ have a checkout (and this kicks in automatically in a bare\nrepo).\n\n> $ git config --unset mailmap.file\n> $ git config mailmap.blob HEAD:.mailmap\n> $ sed -i 's:peff@peff.com:no-valid-address:' .mailmap\n> $ git log -1 --author 'Jeff King'\n\nIn case anybody wants to experiment, there are a bunch of things that\nmake this a non-working example (at least on git.git):\n\n  - my address is actually peff.net :)\n\n  - There mailmap which mentions peff.net maps peff@github.com to\n    peff.net, so this change would require --author=peff@github.com.\n\n  - We don't apply mailmaps for the default output of \"git log\". You can\n    format with \"%aN %aE\", or just use \"git shortlog -ns --author=peff\"\n    which does map.\n\nBut that aside, yeah, you can make an argument to expect one way or the\nother, depending on the situation you set up. I don't have a strong\nfeeling about it, but my gut feeling is that no ordering is\nsignificantly better than the other, and that puts me in favor of\nleaving it as-is purely out of inertia and backwards-compatibility.\n\n-Peff\n"}]}