On Fri, Jun 21 2019, Phil Hord wrote: > On Sat, Jun 15, 2019 at 1:19 AM Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> wrote: >> On Sat, Jun 15 2019, Phil Hord wrote: >> >> > At $work we have a long time employee who has changed their name from >> > Alice to Bob. Bob doesn't want anyone to call him "Alice" anymore and >> > is prone to be offended if they do. This is called "deadnaming". > ... >> What should be done is to extend the .mailmap support to other >> cases. I.e. make tools like blame, shortlog etc. show the equivalent of >> %aN and %aE by default. > > It seems that shortlog and blame do use %aE and %aN by default. Even > log does. It is only because I didn't know about %aN 10 years ago > that my custom log format does not. > > It's a pity the format author has the option to ignore the mailmap. I > think it's a choice commonly made by mistake rather than intention. I > wonder if anyone would mind a forced-override config. Maybe a force > flag in the .mailmap file itself. > > <cto@xxxxxxxxxx> <cto@xxxxxxxxxxx> > Other Author <other@xxxxxxxxx> nick2 <bugs@xxxxxxxxxx> > Alice Doe <alice.doe@xxxxxxxx> <bob.doe@xxxxxxx> --force Yeah I'm sure a lot of people who do %an really mean %aN, but blanket forcing it seems a recipe for breakage since "log" and friends are also used as plumbing where you really mean "what does it say in this commit object". E.g. I use %an intentionally for a company-internal tool to map an Alice to Bob for reporting purposes, which presumably you'd also want. But yeah, there'll be other uses that didn't intend it. I think probably the best way forward is to just make git use %aN by default in porcelain, and outside users presumably would get reports about such issues eventually in cases like this where someone cared. >> This topic was discussed at the last git contributor summit (brought up >> by CB Bailey) resulting in this patch, which I see didn't make it in & >> needs to be resurrected again: >> https://public-inbox.org/git/20181212171052.13415-1-cb@xxxxxxxxxxxxx/ > > Thanks for the link. > > I didn't know about config options for mailmap.file and log.mailmap > before. These do make this option much more useful, especially when we > can insert default settings for them into /etc/gitconfig across the > company. Right, and to the extent that we don't --use-mailmap by default I think that's mainly because nobody's cared enough to advocate for it. I think it would be a sensible default.
