{"thread":{"id":"51319","subject":"Deadname rewriting","startedAt":"2019-06-15T01:54:42Z","lastAt":"2019-06-21T22:24:28Z","messageCount":8,"participants":["Phil Hord","Andreas Schwab","Ævar Arnfjörð Bjarmason","Philip Oakley","CB Bailey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"377289","messageId":"CABURp0poUjSBTTFUXP8dAmJ=37qvpe64=o+t_+mHOiK9Cv+=kg@mail.gmail.com","threadId":"51319","inReplyTo":null,"subject":"Deadname rewriting","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2019-06-15T01:54:26Z","receivedAt":"2019-06-15T01:54:42Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"I know name-scrubbing is already covered in filter-branch and other\nplaces. But we have a scenario becoming more common that makes it a\nmore sensitive topic.\n\nAt $work we have a long time employee who has changed their name from\nAlice to Bob. Bob doesn't want anyone to call him \"Alice\" anymore and\nis prone to be offended if they do. This is called \"deadnaming\".\n\nWe are able to convince most of our work tools to expunge the deadname\nfrom usage anywhere, but git stubbornly calls Bob \"Alice\" whenever\nsomeone asks for \"git blame\" or checks in \"git log\".\n\nWe could rewrite history with filter-branch, but that's quite\ndisruptive. I found some alternatives.\n\n.mailmap seems perfect for this task, but it doesn't work everywhere\n(blame, log, etc.). Also, it requires the deadname to be forever\nproclaimed in the .mailmap file itself.\n\n`git replace` works rather nicely, except all of Bob's old commits\nshow \"replaced\" in the decorator list. Also, it doesn't propagate well\nfrom the central server since `refs/replaces` namespace isn't fetched\nnormally. But in case anyone wants it, here's what I did:\n\ngit log --author=alice.smith --format=\"%h\" --all |\n while read hash ; do\n GIT_EDITOR='sed -i -e s/Alice Smith/Bob Smith/g' -e\n's/alice.smith/bob.smith/' \\\n git replace --edit $hash\n done\ngit push origin 'refs/replace/*:refs/replace/*'\n\nI'd quite like the .mailmap solution to work, and I might flesh that\nout that some day.\n\nIt feels like `.git/info/grafts` would work the best if it could be\ndistributed with the project, but I'm pretty sure that's a non-starter\nfor many reasons.\n\nAny other ideas? Has anyone here encountered this already?\n"},{"id":"377291","messageId":"m27e9nux3r.fsf@linux-m68k.org","threadId":"51319","inReplyTo":"CABURp0poUjSBTTFUXP8dAmJ=37qvpe64=o+t_+mHOiK9Cv+=kg@mail.gmail.com","subject":"Re: Deadname rewriting","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2019-06-15T07:27:36Z","receivedAt":"2019-06-15T07:27:44Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Jun 14 2019, Phil Hord wrote:\n\n> It feels like `.git/info/grafts` would work the best if it could be\n> distributed with the project, but I'm pretty sure that's a non-starter\n> for many reasons.\n\nThe graft file is obsoleted by git replace.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"377292","messageId":"87sgsb8dmx.fsf@evledraar.gmail.com","threadId":"51319","inReplyTo":"CABURp0poUjSBTTFUXP8dAmJ=37qvpe64=o+t_+mHOiK9Cv+=kg@mail.gmail.com","subject":"Re: Deadname rewriting","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-06-15T08:19:02Z","receivedAt":"2019-06-15T08:20:48Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Jun 15 2019, Phil Hord wrote:\n\n> I know name-scrubbing is already covered in filter-branch and other\n> places. But we have a scenario becoming more common that makes it a\n> more sensitive topic.\n>\n> At $work we have a long time employee who has changed their name from\n> Alice to Bob. Bob doesn't want anyone to call him \"Alice\" anymore and\n> is prone to be offended if they do. This is called \"deadnaming\".\n>\n> We are able to convince most of our work tools to expunge the deadname\n> from usage anywhere, but git stubbornly calls Bob \"Alice\" whenever\n> someone asks for \"git blame\" or checks in \"git log\".\n>\n> We could rewrite history with filter-branch, but that's quite\n> disruptive. I found some alternatives.\n>\n> .mailmap seems perfect for this task, but it doesn't work everywhere\n> (blame, log, etc.). Also, it requires the deadname to be forever\n> proclaimed in the .mailmap file itself.\n>\n> `git replace` works rather nicely, except all of Bob's old commits\n> show \"replaced\" in the decorator list. Also, it doesn't propagate well\n> from the central server since `refs/replaces` namespace isn't fetched\n> normally. But in case anyone wants it, here's what I did:\n>\n> git log --author=alice.smith --format=\"%h\" --all |\n> while read hash ; do\n> GIT_EDITOR='sed -i -e s/Alice Smith/Bob Smith/g' -e\n> 's/alice.smith/bob.smith/' \\\n> git replace --edit $hash\n> done\n> git push origin 'refs/replace/*:refs/replace/*'\n>\n> I'd quite like the .mailmap solution to work, and I might flesh that\n> out that some day.\n>\n> It feels like `.git/info/grafts` would work the best if it could be\n> distributed with the project, but I'm pretty sure that's a non-starter\n> for many reasons.\n>\n> Any other ideas? Has anyone here encountered this already?\n\nWhat should be done is to extend the .mailmap support to other\ncases. I.e. make tools like blame, shortlog etc. show the equivalent of\n%aN and %aE by default.\n\nThis topic was discussed at the last git contributor summit (brought up\nby CB Bailey) resulting in this patch, which I see didn't make it in &\nneeds to be resurrected again:\nhttps://public-inbox.org/git/20181212171052.13415-1-cb@hashpling.org/\n\nSo, patches welcome :)\n\nWhat's not going to be supported is some notion of 100% forgetting that\nthere was ever an Alice that's now called Bob. They did in fact create\ncommit objects with \"Alice\" in them, and low-level plumbing like\n\"cat-file -p \" is always going to show that, and there's going\nto be the mapping in .mailmap.\n\nBut as far as porcelain UI things that would show the mailmapped value\ngoes those can be made to always show \"Bob\".\n\nUnless of course your $work is willing to completely rewrite the repo...\n"},{"id":"377373","messageId":"95cde058-37b3-a168-ff45-97f9501305a0@iee.org","threadId":"51319","inReplyTo":"87sgsb8dmx.fsf@evledraar.gmail.com","subject":"Re: Deadname rewriting","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2019-06-17T21:21:35Z","receivedAt":"2019-06-17T21:36:22Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 15/06/2019 09:19, Ævar Arnfjörð Bjarmason wrote:\n> On Sat, Jun 15 2019, Phil Hord wrote:\n>\n>> I know name-scrubbing is already covered in filter-branch and other\n>> places. But we have a scenario becoming more common that makes it a\n>> more sensitive topic.\n>>\n>> At $work we have a long time employee who has changed their name from\n>> Alice to Bob. Bob doesn't want anyone to call him \"Alice\" anymore and\n>> is prone to be offended if they do. This is called \"deadnaming\".\n>>\n>> We are able to convince most of our work tools to expunge the deadname\n>> from usage anywhere, but git stubbornly calls Bob \"Alice\" whenever\n>> someone asks for \"git blame\" or checks in \"git log\".\n>>\n>> We could rewrite history with filter-branch, but that's quite\n>> disruptive. I found some alternatives.\n>>\n>> .mailmap seems perfect for this task, but it doesn't work everywhere\n>> (blame, log, etc.). Also, it requires the deadname to be forever\n>> proclaimed in the .mailmap file itself.\n>>\n>> `git replace` works rather nicely, except all of Bob's old commits\n>> show \"replaced\" in the decorator list. Also, it doesn't propagate well\n>> from the central server since `refs/replaces` namespace isn't fetched\n>> normally. But in case anyone wants it, here's what I did:\n>>\n>> git log --author=alice.smith --format=\"%h\" --all |\n>> while read hash ; do\n>> GIT_EDITOR='sed -i -e s/Alice Smith/Bob Smith/g' -e\n>> 's/alice.smith/bob.smith/' \\\n>> git replace --edit $hash\n>> done\n>> git push origin 'refs/replace/*:refs/replace/*'\n>>\n>> I'd quite like the .mailmap solution to work, and I might flesh that\n>> out that some day.\n>>\n>> It feels like `.git/info/grafts` would work the best if it could be\n>> distributed with the project, but I'm pretty sure that's a non-starter\n>> for many reasons.\n>>\n>> Any other ideas? Has anyone here encountered this already?\n> What should be done is to extend the .mailmap support to other\n> cases. I.e. make tools like blame, shortlog etc. show the equivalent of\n> %aN and %aE by default.\n>\n> This topic was discussed at the last git contributor summit (brought up\n> by CB Bailey) resulting in this patch, which I see didn't make it in &\n> needs to be resurrected again:\n> https://public-inbox.org/git/20181212171052.13415-1-cb@hashpling.org/\n>\n> So, patches welcome :)\n>\n> What's not going to be supported is some notion of 100% forgetting that\n> there was ever an Alice that's now called Bob. They did in fact create\n> commit objects with \"Alice\" in them, and low-level plumbing like\n> \"cat-file -p \" is always going to show that, and there's going\n> to be the mapping in .mailmap.\n>\n> But as far as porcelain UI things that would show the mailmapped value\n> goes those can be made to always show \"Bob\".\n>\n> Unless of course your $work is willing to completely rewrite the repo...\nThis may become a bigger issue for corporates that prevents Git from \nbeing used because it doesn't handle the _legal requirements_ for proper \ncurrent `known-by:` naming.\n\nI found this [1] on the UK Parliament website that also covers \n'deadnaming', and the potential misunderstandings about what is (and is \nnot) a (unnecessary) 'legal name'.\n\nIt may be an option for the SHA1 transition to also include, as an \nindependent step, the appropriate mailmap conversion for dead-names \n(which is a private document owned by the hosting repo owner - see GDPR \nData Controller responsibilities).\n\nIf author/committer renaming is done as part of a full hash conversion \n(with a golden repo providing hash mapping) then it is less of a problem \nfor a one-shot conversion, but still an issue for everyday name changes \n(including those from divorce, adoption, etc). Maybe even convert (swap) \nthe ascii/utf-8 names for unique hashes (in the repo) for reverse look \nup of the latest known-by name (getting a bit complicated here)\n\nThe distributed nature of the classic Git open source usage may have \nsimilar issues to that of gmane, where it pulled the hosting of email \nlists. A legal case is likely needed before any level of clarification \nis obtained (which will still have overlaps!)\n\nThe mailmap is probably not the right place for holding deadname \nconversions as they should not be public, but it may be a partial \nworkaround to reduce visibility of deadnames.\n\nPhilip\n\n[1] \nhttps://publications.parliament.uk/pa/cm201516/cmselect/cmwomeq/390/39009.htm\n"},{"id":"377375","messageId":"87pnnb970c.fsf@evledraar.gmail.com","threadId":"51319","inReplyTo":"95cde058-37b3-a168-ff45-97f9501305a0@iee.org","subject":"Re: Deadname rewriting","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-06-17T22:33:39Z","receivedAt":"2019-06-17T22:33:44Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Jun 17 2019, Philip Oakley wrote:\n\n> On 15/06/2019 09:19, Ævar Arnfjörð Bjarmason wrote:\n>> On Sat, Jun 15 2019, Phil Hord wrote:\n>>\n>>> I know name-scrubbing is already covered in filter-branch and other\n>>> places. But we have a scenario becoming more common that makes it a\n>>> more sensitive topic.\n>>>\n>>> At $work we have a long time employee who has changed their name from\n>>> Alice to Bob. Bob doesn't want anyone to call him \"Alice\" anymore and\n>>> is prone to be offended if they do. This is called \"deadnaming\".\n>>>\n>>> We are able to convince most of our work tools to expunge the deadname\n>>> from usage anywhere, but git stubbornly calls Bob \"Alice\" whenever\n>>> someone asks for \"git blame\" or checks in \"git log\".\n>>>\n>>> We could rewrite history with filter-branch, but that's quite\n>>> disruptive. I found some alternatives.\n>>>\n>>> .mailmap seems perfect for this task, but it doesn't work everywhere\n>>> (blame, log, etc.). Also, it requires the deadname to be forever\n>>> proclaimed in the .mailmap file itself.\n>>>\n>>> `git replace` works rather nicely, except all of Bob's old commits\n>>> show \"replaced\" in the decorator list. Also, it doesn't propagate well\n>>> from the central server since `refs/replaces` namespace isn't fetched\n>>> normally. But in case anyone wants it, here's what I did:\n>>>\n>>> git log --author=alice.smith --format=\"%h\" --all |\n>>> while read hash ; do\n>>> GIT_EDITOR='sed -i -e s/Alice Smith/Bob Smith/g' -e\n>>> 's/alice.smith/bob.smith/' \\\n>>> git replace --edit $hash\n>>> done\n>>> git push origin 'refs/replace/*:refs/replace/*'\n>>>\n>>> I'd quite like the .mailmap solution to work, and I might flesh that\n>>> out that some day.\n>>>\n>>> It feels like `.git/info/grafts` would work the best if it could be\n>>> distributed with the project, but I'm pretty sure that's a non-starter\n>>> for many reasons.\n>>>\n>>> Any other ideas? Has anyone here encountered this already?\n>> What should be done is to extend the .mailmap support to other\n>> cases. I.e. make tools like blame, shortlog etc. show the equivalent of\n>> %aN and %aE by default.\n>>\n>> This topic was discussed at the last git contributor summit (brought up\n>> by CB Bailey) resulting in this patch, which I see didn't make it in &\n>> needs to be resurrected again:\n>> https://public-inbox.org/git/20181212171052.13415-1-cb@hashpling.org/\n>>\n>> So, patches welcome :)\n>>\n>> What's not going to be supported is some notion of 100% forgetting that\n>> there was ever an Alice that's now called Bob. They did in fact create\n>> commit objects with \"Alice\" in them, and low-level plumbing like\n>> \"cat-file -p \" is always going to show that, and there's going\n>> to be the mapping in .mailmap.\n>>\n>> But as far as porcelain UI things that would show the mailmapped value\n>> goes those can be made to always show \"Bob\".\n>>\n>> Unless of course your $work is willing to completely rewrite the repo...\n> This may become a bigger issue for corporates that prevents Git from\n> being used because it doesn't handle the _legal requirements_ for\n> proper current `known-by:` naming.\n>\n> I found this [1] on the UK Parliament website that also covers\n> 'deadnaming', and the potential misunderstandings about what is (and\n> is not) a (unnecessary) 'legal name'.\n>\n> It may be an option for the SHA1 transition to also include, as an\n> independent step, the appropriate mailmap conversion for dead-names\n> (which is a private document owned by the hosting repo owner - see\n> GDPR Data Controller responsibilities).\n>\n> If author/committer renaming is done as part of a full hash conversion\n> (with a golden repo providing hash mapping) then it is less of a\n> problem for a one-shot conversion, but still an issue for everyday\n> name changes (including those from divorce, adoption, etc). Maybe even\n> convert (swap) the ascii/utf-8 names for unique hashes (in the repo)\n> for reverse look up of the latest known-by name (getting a bit\n> complicated here)\n>\n> The distributed nature of the classic Git open source usage may have\n> similar issues to that of gmane, where it pulled the hosting of email\n> lists. A legal case is likely needed before any level of clarification\n> is obtained (which will still have overlaps!)\n>\n> The mailmap is probably not the right place for holding deadname\n> conversions as they should not be public, but it may be a partial\n> workaround to reduce visibility of deadnames.\n>\n> [1]\n> https://publications.parliament.uk/pa/cm201516/cmselect/cmwomeq/390/39009.htm\n\nI don't see how tacking this onto the SHA-1->SHA-256 hash transition\ncould ever work.\n\nIgnoring the issues with how it wouldn't work with the current plan as\ndesigned, you'd have a mostly 1=1 mapping between the two hashes, except\nin cases where commits from \"Alice\" wouldn't 1=1 map, because they'd\nbeen subject to some mailmap munging you didn't have access to to map\nthem to \"Bob\".\n\nI'd think that in the context of a non-public work repository you'd just\nleak the same information anyway. People wanting to deadname themselves\nis relatively rare, so it wouldn't be hard in most cases to infer the\nmissing data, and you'd be back at square 1.\n\nThat, and even if it somehow worked the hash transition is a one-off\nthing, and you'd presumably want this on an ongoing basis, so you'd need\nsome other mechanism.\n\nI think there's certainly a place for better support for gracefully\nhandling complete history rewriting in a centralized workflow better\nwithin git.\n\nThat sort of thing is useful for other things, e.g. you might want to\nrewrite out some old big blob in your history, or erase any record that\nyou used to use an indenting style that's not in fashion.\n\nSo basically an improvement to the refs/replaces facility where clients\nwould opt-in to eagerly forget the old history, and since it your $work\nyou'd have a central server you could enforce the eventual full\ntransition, and clients wouldn't get upset about the non-fast-forward.\n"},{"id":"377776","messageId":"CABURp0p2Z=qD2gF59AHBLaRn9iiTOeJyNXYsQDNk-_KEC4uSGg@mail.gmail.com","threadId":"51319","inReplyTo":"87sgsb8dmx.fsf@evledraar.gmail.com","subject":"Re: Deadname rewriting","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2019-06-21T21:12:37Z","receivedAt":"2019-06-21T21:12:53Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Sat, Jun 15, 2019 at 1:19 AM Ævar Arnfjörð Bjarmason\n wrote:\n> On Sat, Jun 15 2019, Phil Hord wrote:\n>\n> > At $work we have a long time employee who has changed their name from\n> > Alice to Bob. Bob doesn't want anyone to call him \"Alice\" anymore and\n> > is prone to be offended if they do. This is called \"deadnaming\".\n...\n> What should be done is to extend the .mailmap support to other\n> cases. I.e. make tools like blame, shortlog etc. show the equivalent of\n> %aN and %aE by default.\n\nIt seems that shortlog and blame do use %aE and %aN by default. Even\nlog does. It is only because I didn't know about %aN 10 years ago\nthat my custom log format does not.\n\nIt's a pity the format author has the option to ignore the mailmap. I\nthink it's a choice commonly made by mistake rather than intention. I\nwonder if anyone would mind a forced-override config. Maybe a force\nflag in the .mailmap file itself.\n\n \n Other Author nick2 \n Alice Doe --force\n\n\n> This topic was discussed at the last git contributor summit (brought up\n> by CB Bailey) resulting in this patch, which I see didn't make it in &\n> needs to be resurrected again:\n> https://public-inbox.org/git/20181212171052.13415-1-cb@hashpling.org/\n\nThanks for the link.\n\nI didn't know about config options for mailmap.file and log.mailmap\nbefore. These do make this option much more useful, especially when we\ncan insert default settings for them into /etc/gitconfig across the\ncompany.\n"},{"id":"377777","messageId":"877e9e8vxt.fsf@evledraar.gmail.com","threadId":"51319","inReplyTo":"CABURp0p2Z=qD2gF59AHBLaRn9iiTOeJyNXYsQDNk-_KEC4uSGg@mail.gmail.com","subject":"Re: Deadname rewriting","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-06-21T21:34:06Z","receivedAt":"2019-06-21T21:34:11Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Jun 21 2019, Phil Hord wrote:\n\n> On Sat, Jun 15, 2019 at 1:19 AM Ævar Arnfjörð Bjarmason\n> wrote:\n>> On Sat, Jun 15 2019, Phil Hord wrote:\n>>\n>> > At $work we have a long time employee who has changed their name from\n>> > Alice to Bob. Bob doesn't want anyone to call him \"Alice\" anymore and\n>> > is prone to be offended if they do. This is called \"deadnaming\".\n> ...\n>> What should be done is to extend the .mailmap support to other\n>> cases. I.e. make tools like blame, shortlog etc. show the equivalent of\n>> %aN and %aE by default.\n>\n> It seems that shortlog and blame do use %aE and %aN by default. Even\n> log does. It is only because I didn't know about %aN 10 years ago\n> that my custom log format does not.\n>\n> It's a pity the format author has the option to ignore the mailmap. I\n> think it's a choice commonly made by mistake rather than intention. I\n> wonder if anyone would mind a forced-override config. Maybe a force\n> flag in the .mailmap file itself.\n>\n> \n> Other Author nick2 \n> Alice Doe --force\n\nYeah I'm sure a lot of people who do %an really mean %aN, but blanket\nforcing it seems a recipe for breakage since \"log\" and friends are also\nused as plumbing where you really mean \"what does it say in this commit\nobject\".\n\nE.g. I use %an intentionally for a company-internal tool to map an Alice\nto Bob for reporting purposes, which presumably you'd also want.\n\nBut yeah, there'll be other uses that didn't intend it. I think probably\nthe best way forward is to just make git use %aN by default in\nporcelain, and outside users presumably would get reports about such\nissues eventually in cases like this where someone cared.\n\n>> This topic was discussed at the last git contributor summit (brought up\n>> by CB Bailey) resulting in this patch, which I see didn't make it in &\n>> needs to be resurrected again:\n>> https://public-inbox.org/git/20181212171052.13415-1-cb@hashpling.org/\n>\n> Thanks for the link.\n>\n> I didn't know about config options for mailmap.file and log.mailmap\n> before. These do make this option much more useful, especially when we\n> can insert default settings for them into /etc/gitconfig across the\n> company.\n\nRight, and to the extent that we don't --use-mailmap by default I think\nthat's mainly because nobody's cared enough to advocate for it. I think\nit would be a sensible default.\n"},{"id":"377778","messageId":"20190621221650.hoet5juwjhjcw5mh@hashpling.org","threadId":"51319","inReplyTo":"877e9e8vxt.fsf@evledraar.gmail.com","subject":"Re: Deadname rewriting","fromName":"CB Bailey","fromEmail":"cb@hashpling.org","sentAt":"2019-06-21T22:16:50Z","receivedAt":"2019-06-21T22:24:28Z","isPatch":false,"sender":{"key":"cb@hashpling.org","avatar":null},"body":"On Fri, Jun 21, 2019 at 11:34:06PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> >> This topic was discussed at the last git contributor summit (brought up\n> >> by CB Bailey) resulting in this patch, which I see didn't make it in &\n> >> needs to be resurrected again:\n> >> https://public-inbox.org/git/20181212171052.13415-1-cb@hashpling.org/\n> >\n> > Thanks for the link.\n> >\n> > I didn't know about config options for mailmap.file and log.mailmap\n> > before. These do make this option much more useful, especially when we\n> > can insert default settings for them into /etc/gitconfig across the\n> > company.\n> \n> Right, and to the extent that we don't --use-mailmap by default I think\n> that's mainly because nobody's cared enough to advocate for it. I think\n> it would be a sensible default.\n\nThat was this patch:\n\nhttps://public-inbox.org/git/20181213120940.26477-1-cb@hashpling.org/\n\nThere were no objections so I was going to re-propose it but I haven't\ngot around to this for a number of reasons, many of which are not Git\nrelated. Ideally, I wanted to fix all of the known issues with mailmap\nsuch as some behaviors of shortlog fixed with the shortlog patch above.\n\nI also noticed some more artifacts that I would like to be fixed. In\nparticular the RFC 822 style \"trailers\" should be rewritten by default.\n\nHaving something like this pop up is not likely to be acceptable in a\nproject which uses trailers:\n\ncommit abcd...\nAuthor: Bob \n\n important commit message\n\n Signed-off-by: Alice