{"thread":{"id":"59333","subject":"Let us not call it git blame","startedAt":"2023-03-02T22:01:50Z","lastAt":"2023-03-09T20:29:30Z","messageCount":10,"participants":["Dinesh Dharmawardena","brian m. carlson","Junio C Hamano","rsbecker@nexbridge.com","demerphq","Peter Hadlaw","Ævar Arnfjörð Bjarmason","Elijah Lynn"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"472935","messageId":"SY6P282MB378273980F5BC9084EEF74EF92B29@SY6P282MB3782.AUSP282.PROD.OUTLOOK.COM","threadId":"59333","inReplyTo":"SY6P282MB3782FD975E6F39951C5A43DA92B29@SY6P282MB3782.AUSP282.PROD.OUTLOOK.COM","subject":"Let us not call it git blame","fromName":"Dinesh Dharmawardena","fromEmail":"dinesh_dh@outlook.com","sentAt":"2023-03-02T22:00:59Z","receivedAt":"2023-03-02T22:01:50Z","isPatch":false,"sender":{"key":"dinesh_dh@outlook.com","avatar":null},"body":"Hi\n\nI am writing to you to request that the term blame in git blame be replaced with something that does not sound so blameful. I’m an SRE and we actively try promote a blameless culture as such industry tooling should also follow suit imo. Progressively phasing this term out with a better alias would be great.\n\nCheers\nDinesh\n\nSent from my iPhone"},{"id":"472942","messageId":"ZAEgRDelTlNZRJ5J@tapette.crustytoothpaste.net","threadId":"59333","inReplyTo":"SY6P282MB378273980F5BC9084EEF74EF92B29@SY6P282MB3782.AUSP282.PROD.OUTLOOK.COM","subject":"Re: Let us not call it git blame","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2023-03-02T22:16:36Z","receivedAt":"2023-03-02T22:16:43Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2023-03-02 at 22:00:59, Dinesh Dharmawardena wrote:\n> Hi\n> \n> I am writing to you to request that the term blame in git blame be replaced with something that does not sound so blameful. I’m an SRE and we actively try promote a blameless culture as such industry tooling should also follow suit imo. Progressively phasing this term out with a better alias would be great.\n\nI believe there's already an alias for it, git annotate, if you'd prefer\nto use that. The name \"blame\" came in with CVS, with the synonym\n\"annotate\", so it's well understood, but you can use whichever alias you\nprefer.\n\nI do think there may some differences in the defaults between git\nannotate and git blame, but if someone wanted to send in a patch for an\noption to make annotate produce identical output to blame, then I think\nit could be a full replacement.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"472944","messageId":"xmqqfsamiul2.fsf@gitster.g","threadId":"59333","inReplyTo":"ZAEgRDelTlNZRJ5J@tapette.crustytoothpaste.net","subject":"Re: Let us not call it git blame","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-03-02T23:47:53Z","receivedAt":"2023-03-02T23:47:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On 2023-03-02 at 22:00:59, Dinesh Dharmawardena wrote:\n>> \n>> I am writing to you to request that the term blame in git blame\n>> be replaced with something that does not sound so blameful. I’m\n>> an SRE and we actively try promote a blameless culture as such\n>> industry tooling should also follow suit imo. Progressively\n>> phasing this term out with a better alias would be great.\n\nI actually do not think \"git blame\" is incompatible with blameless\nculture at all, unless you blindly say \"this word is bad, that word\nis not\" without thinking. Blameless culture is about not blaming\nthe _person_ who made an earlier mistake, but \"git blame\" is not\nabout finding a person who contributed the badness to the codebase.\n\nIt is all about which _commit_ contributed badness to the current\ncodebase (i.e. \"these commits are to be blamed for the current\nbreakage that made us lose $XM\") and it is up to the users how to\ninterpret the story behind these found commits. It often would not\nbe the \"fault\" of the author alone, and striving for blameless\nculture is to find out what led to the mistakes in these commits.\n\n> I believe there's already an alias for it, git annotate, if you'd\n> prefer to use that. The name \"blame\" came in with CVS, with the\n> synonym \"annotate\", so it's well understood, but you can use\n> whichever alias you prefer.\n>\n> I do think there may some differences in the defaults between git\n> annotate and git blame, but if someone wanted to send in a patch for an\n> option to make annotate produce identical output to blame, then I think\n> it could be a full replacement.\n\nAt that point we can retire \"git blame\" and make it a built-in alias\nto \"git annotate --behave-like-git-blame\". Then we will come full\ncircle ;-)\n\nThanks.\n"},{"id":"472945","messageId":"003201d94d64$1e732030$5b596090$@nexbridge.com","threadId":"59333","inReplyTo":"xmqqfsamiul2.fsf@gitster.g","subject":"RE: Let us not call it git blame","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2023-03-03T00:07:12Z","receivedAt":"2023-03-03T00:07:37Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Thursday, March 2, 2023 6:48 PM, Junio C Hamano wrote:\n>\"brian m. carlson\" writes:\n>\n>> On 2023-03-02 at 22:00:59, Dinesh Dharmawardena wrote:\n>>>\n>>> I am writing to you to request that the term blame in git blame be\n>>> replaced with something that does not sound so blameful. I’m an SRE\n>>> and we actively try promote a blameless culture as such industry\n>>> tooling should also follow suit imo. Progressively phasing this term\n>>> out with a better alias would be great.\n>\n>I actually do not think \"git blame\" is incompatible with blameless culture at all,\n>unless you blindly say \"this word is bad, that word is not\" without thinking. Blameless\n>culture is about not blaming the _person_ who made an earlier mistake, but \"git\n>blame\" is not about finding a person who contributed the badness to the codebase.\n>\n>It is all about which _commit_ contributed badness to the current codebase (i.e.\n>\"these commits are to be blamed for the current breakage that made us lose $XM\")\n>and it is up to the users how to interpret the story behind these found commits. It\n>often would not be the \"fault\" of the author alone, and striving for blameless culture\n>is to find out what led to the mistakes in these commits.\n>\n>> I believe there's already an alias for it, git annotate, if you'd\n>> prefer to use that. The name \"blame\" came in with CVS, with the\n>> synonym \"annotate\", so it's well understood, but you can use whichever\n>> alias you prefer.\n>>\n>> I do think there may some differences in the defaults between git\n>> annotate and git blame, but if someone wanted to send in a patch for\n>> an option to make annotate produce identical output to blame, then I\n>> think it could be a full replacement.\n>\n>At that point we can retire \"git blame\" and make it a built-in alias to \"git annotate --\n>behave-like-git-blame\". Then we will come full circle ;-)\n\nI think you have a good point here. Blame is associated with the commit which is not a specific person (might be a group though). In some (a few, but growing) companies I am dealing with, the core.user and core.email are associated with a nameless single sign on (SSO), or tokenized user, in order to be compliant from a regulatory standpoint. This includes GDPR in Europe and the Privacy Act in Canada. In these cases, there is no identifying information in the commit itself, but externally in the organization's HR and IT departments where identifying information is tightly controlled. Cause and effect will always exist, no matter how one might choose to semantically hide the usage. Words do matter, but identifying information may not for much longer. Perhaps that approach might help the OP's organization in their jurisdiction, to dissociate the commit from the person except during a specific audit context.\n\n"},{"id":"472948","messageId":"ZAFN2ZoOQzUC/nHo@tapette.crustytoothpaste.net","threadId":"59333","inReplyTo":"xmqqfsamiul2.fsf@gitster.g","subject":"Re: Let us not call it git blame","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2023-03-03T01:31:05Z","receivedAt":"2023-03-03T01:31:17Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2023-03-02 at 23:47:53, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n> > On 2023-03-02 at 22:00:59, Dinesh Dharmawardena wrote:\n> >> \n> >> I am writing to you to request that the term blame in git blame\n> >> be replaced with something that does not sound so blameful. I’m\n> >> an SRE and we actively try promote a blameless culture as such\n> >> industry tooling should also follow suit imo. Progressively\n> >> phasing this term out with a better alias would be great.\n> \n> I actually do not think \"git blame\" is incompatible with blameless\n> culture at all, unless you blindly say \"this word is bad, that word\n> is not\" without thinking. Blameless culture is about not blaming\n> the _person_ who made an earlier mistake, but \"git blame\" is not\n> about finding a person who contributed the badness to the codebase.\n> \n> It is all about which _commit_ contributed badness to the current\n> codebase (i.e. \"these commits are to be blamed for the current\n> breakage that made us lose $XM\") and it is up to the users how to\n> interpret the story behind these found commits. It often would not\n> be the \"fault\" of the author alone, and striving for blameless\n> culture is to find out what led to the mistakes in these commits.\n\nI don't even think it's that all the time. Sometimes I've used git\nblame to find the author of a commit to ask them questions about a\ncomment or change later on, or to find a commit message or pull request\nto understand why a change was made.\n\nI'm almost always more interested in learning more about the rationale\nor reasoning for a commit than blaming a particular user. I have used\ngit blame in the past to find the _team_ that introduced a regression\nfor assigning bugs in triage when the cause is clear (since they'd have\nthe relevant context to understand the necessary change better), but\nit's very uncommon that I actually use it in anger to blame to a\nparticular person.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"472949","messageId":"CANgJU+XT3h4b40Nr8uq_j4NyY0ka43vPghN4fJx8B=qcCHoUaA@mail.gmail.com","threadId":"59333","inReplyTo":"SY6P282MB378273980F5BC9084EEF74EF92B29@SY6P282MB3782.AUSP282.PROD.OUTLOOK.COM","subject":"Re: Let us not call it git blame","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2023-03-03T08:28:37Z","receivedAt":"2023-03-03T08:29:05Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On Thu, 2 Mar 2023 at 23:21, Dinesh Dharmawardena wrote:\n>\n> Hi\n>\n> I am writing to you to request that the term blame in git blame be replaced with something that does not sound so blameful. I’m an SRE and we actively try promote a blameless culture as such industry tooling should also follow suit imo. Progressively phasing this term out with a better alias would be great.\n\nJust set up an alias that maps `git credit` to `git blame`, and you are done.\n\n$ git config --global alias.credit blame\n\nI dont think there is or ever will be much traction to rename this\ncommand, it is short and self descriptive.\n\nBlameless culture is great, but it is about \"not finger pointing\", not\nabout what tools you use. Your company's management and internal\nculture keepers are more important for setting this tone than the\ntools you use. If they don't actually practice not finger pointing\nthen renaming the tool won't dont anything, and if they do actually\npractice then the name of the tool won't matter either.\n\ncheers,\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"472950","messageId":"CANgJU+Vhh091E+n8B6WaMKh6K2kAG29a2M8Oqm-Zvrr8kRrTRw@mail.gmail.com","threadId":"59333","inReplyTo":"003201d94d64$1e732030$5b596090$@nexbridge.com","subject":"Re: Let us not call it git blame","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2023-03-03T08:55:31Z","receivedAt":"2023-03-03T08:55:47Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On Fri, 3 Mar 2023 at 02:24, wrote:\n> the core.user and core.email are associated with a nameless single sign on (SSO), or tokenized user, in order to be compliant from a regulatory standpoint. This includes GDPR in Europe and the Privacy Act in Canada. In these cases, there is no identifying information in the commit itself, but externally in the organization's HR and IT departments where identifying information is tightly controlled.\n\nI wish git would make this a core feature. I think it is one of the\nfew oversights in the core design of git that there isn't a built\nindirection on author and committer data. It should be possible to\n\"forget\" an author or committer without having to rewrite the repo.\nIMO, one day in the future this design deficiency will cause some very\nexpensive remedial work in the git space, and IMO it is only a\nquestion of when, but sods law says it will be at some very\ninconvenient time.\n\nIt really should be technically simple to remedy as well, replacing\nauthor and committer data with a hash or ID which is used to indirect\ninto a file of author information that is *not* version controlled\nwould essentially solve it. If someone wanted to change their name\nthey would update the file, if they wanted to be forgotten they could\nsimply delete that line from the file and push it. While not a 100%\ncomplete solution it would go a LONG way to address most people's\nprivacy concerns and other practical identity management concerns (eg,\n\"my email changed\"). The .mailmap support is just a bandaid, it\ndoesn't actually address the core problem and in fact in some ways it\nmakes it worse. If git provided support for hooking the id lookups\nthen queries to resolve the ID or names could be made to a third party\nsoftware or service, like an open source service for the public, or an\ninternal service owned by HR in the corporate context. It isn't rocket\nscience, it just requires recognition that names are not static\nidentifiers.\n\ncheers,\nYves\n"},{"id":"472968","messageId":"CABrPy+EhTzMo4OvWNWFr2yc9KSEOzJBSjoBFRQHdnQcc=A_wXA@mail.gmail.com","threadId":"59333","inReplyTo":"SY6P282MB378273980F5BC9084EEF74EF92B29@SY6P282MB3782.AUSP282.PROD.OUTLOOK.COM","subject":"Re: Let us not call it git blame","fromName":"Peter Hadlaw","fromEmail":"hadlawp@gmail.com","sentAt":"2023-03-03T18:28:23Z","receivedAt":"2023-03-03T18:29:09Z","isPatch":false,"sender":{"key":"hadlawp@gmail.com","avatar":"https://gravatar.com/avatar/5c112c7b0f8a2f31347a23b3c9461c416c1047e5f47ba5c0c588272c1f3b1cda?d=mp&s=160"},"body":"End of Roman Empire vibes...\n\nOn Thu, Mar 2, 2023 at 4:03 PM Dinesh Dharmawardena\n wrote:\n>\n> Hi\n>\n> I am writing to you to request that the term blame in git blame be replaced with something that does not sound so blameful. I’m an SRE and we actively try promote a blameless culture as such industry tooling should also follow suit imo. Progressively phasing this term out with a better alias would be great.\n>\n> Cheers\n> Dinesh\n>\n> Sent from my iPhone\n\n\n\n-- \nPeter\n"},{"id":"473119","messageId":"230307.86sfegzrtc.gmgdl@evledraar.gmail.com","threadId":"59333","inReplyTo":"SY6P282MB378273980F5BC9084EEF74EF92B29@SY6P282MB3782.AUSP282.PROD.OUTLOOK.COM","subject":"Re: Let us not call it git blame","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2023-03-07T12:08:20Z","receivedAt":"2023-03-07T12:09:26Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Mar 02 2023, Dinesh Dharmawardena wrote:\n\n> Hi\n>\n> I am writing to you to request that the term blame in git blame be\n> replaced with something that does not sound so blameful. I’m an SRE\n> and we actively try promote a blameless culture as such industry\n> tooling should also follow suit imo. Progressively phasing this term\n> out with a better alias would be great.\n\nYou might be interested in a patch I had to address this, posted a while\nago:\nhttps://lore.kernel.org/git/20190401101246.21418-1-avarab@gmail.com/\n"},{"id":"473315","messageId":"CAJ9KuXxDfK5rOitVaXQbV2ZDZR8U8Xc2HNCbSGP8DUgN+5waUg@mail.gmail.com","threadId":"59333","inReplyTo":"SY6P282MB378273980F5BC9084EEF74EF92B29@SY6P282MB3782.AUSP282.PROD.OUTLOOK.COM","subject":"Re: Let us not call it git blame","fromName":"Elijah Lynn","fromEmail":"elijah@elijahlynn.net","sentAt":"2023-03-09T20:28:55Z","receivedAt":"2023-03-09T20:29:30Z","isPatch":false,"sender":{"key":"elijah@elijahlynn.net","avatar":null},"body":"I've thought about this a bit too. And I like the command `git tell`.\n\nElijah Lynn\nwww.elijahlynn.net\n\nOn Thu, Mar 2, 2023 at 2:02 PM Dinesh Dharmawardena\n wrote:\n>\n> Hi\n>\n> I am writing to you to request that the term blame in git blame be replaced with something that does not sound so blameful. I’m an SRE and we actively try promote a blameless culture as such industry tooling should also follow suit imo. Progressively phasing this term out with a better alias would be great.\n>\n> Cheers\n> Dinesh\n>\n> Sent from my iPhone\n"}]}