RE: Let us not call it git blame

[<rsbecker@nexbridge.com>]

On Thursday, March 2, 2023 6:48 PM, Junio C Hamano wrote:
>"brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
>> On 2023-03-02 at 22:00:59, Dinesh Dharmawardena wrote:
>>>
>>> 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.
>
>I actually do not think "git blame" is incompatible with blameless culture at all,
>unless you blindly say "this word is bad, that word is not" without thinking.  Blameless
>culture is about not blaming the _person_ who made an earlier mistake, but "git
>blame" is not about finding a person who contributed the badness to the codebase.
>
>It is all about which _commit_ contributed badness to the current codebase (i.e.
>"these commits are to be blamed for the current breakage that made us lose $XM")
>and it is up to the users how to interpret the story behind these found commits.  It
>often would not be the "fault" of the author alone, and striving for blameless culture
>is to find out what led to the mistakes in these commits.
>
>> I believe there's already an alias for it, git annotate, if you'd
>> prefer to use that.  The name "blame" came in with CVS, with the
>> synonym "annotate", so it's well understood, but you can use whichever
>> alias you prefer.
>>
>> I do think there may some differences in the defaults between git
>> annotate and git blame, but if someone wanted to send in a patch for
>> an option to make annotate produce identical output to blame, then I
>> think it could be a full replacement.
>
>At that point we can retire "git blame" and make it a built-in alias to "git annotate --
>behave-like-git-blame".  Then we will come full circle ;-)

I 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.