Let us not call it git blame

Let us not call it git blame

[Dinesh Dharmawardena]

Hi

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.

Cheers
Dinesh

Sent from my iPhone

Re: Let us not call it git blame

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

On 2023-03-02 at 22:00:59, Dinesh Dharmawardena wrote:
> Hi
> 
> 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 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.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Let us not call it git blame

[Junio C Hamano]

"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 ;-)

Thanks.

RE: Let us not call it git blame

[rsbecker]

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.

Re: Let us not call it git blame

[demerphq]

On Fri, 3 Mar 2023 at 02:24, <rsbecker@nexbridge.com> wrote:
> 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.

I wish git would make this a core feature.  I think it is one of the
few oversights in the core design of git that there isn't a built
indirection on author and committer data.  It should be possible to
"forget" an author or committer without having to rewrite the repo.
IMO, one day in the future this design deficiency will cause some very
expensive remedial work in the git space, and IMO it is only a
question of when, but sods law says it will be at some very
inconvenient time.

It really should be technically simple to remedy as well, replacing
author and committer data with a hash or ID which is used to indirect
into a file of author information that is *not* version controlled
would essentially solve it.  If someone wanted to change their name
they would update the file, if they wanted to be forgotten they could
simply delete that line from the file and push it.  While not a 100%
complete solution it would go a LONG way to address most people's
privacy concerns and other practical identity management concerns (eg,
"my email changed"). The .mailmap support is just a bandaid, it
doesn't actually address the core problem and in fact in some ways it
makes it worse. If git provided support for hooking the id lookups
then queries to resolve the ID or names could be made to a third party
software or service, like an open source service for the public, or an
internal service owned by HR in the corporate context. It isn't rocket
science, it just requires recognition that names are not static
identifiers.

cheers,
Yves

Re: Let us not call it git blame

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]

On 2023-03-02 at 23:47:53, 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 don't even think it's that all the time.  Sometimes I've used git
blame to find the author of a commit to ask them questions about a
comment or change later on, or to find a commit message or pull request
to understand why a change was made.

I'm almost always more interested in learning more about the rationale
or reasoning for a commit than blaming a particular user.  I have used
git blame in the past to find the _team_ that introduced a regression
for assigning bugs in triage when the cause is clear (since they'd have
the relevant context to understand the necessary change better), but
it's very uncommon that I actually use it in anger to blame to a
particular person.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Let us not call it git blame

[demerphq]

On Thu, 2 Mar 2023 at 23:21, Dinesh Dharmawardena <dinesh_dh@outlook.com> wrote:
>
> Hi
>
> 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.

Just set up an alias that maps `git credit` to `git blame`, and you are done.

$ git config --global alias.credit blame

I dont think there is or ever will be much traction to rename this
command, it is short and self descriptive.

Blameless culture is great, but it is about "not finger pointing", not
about what tools you use. Your company's management and internal
culture keepers are more important for setting this tone than the
tools you use.  If they don't actually practice not finger pointing
then renaming the tool won't dont anything, and if they do actually
practice then the name of the tool won't matter either.

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Let us not call it git blame

[Peter Hadlaw]

End of Roman Empire vibes...

On Thu, Mar 2, 2023 at 4:03 PM Dinesh Dharmawardena
<dinesh_dh@outlook.com> wrote:
>
> Hi
>
> 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.
>
> Cheers
> Dinesh
>
> Sent from my iPhone



-- 
Peter

Re: Let us not call it git blame

[Ævar Arnfjörð Bjarmason]

On Thu, Mar 02 2023, Dinesh Dharmawardena wrote:

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

You might be interested in a patch I had to address this, posted a while
ago:
https://lore.kernel.org/git/20190401101246.21418-1-avarab@gmail.com/

Re: Let us not call it git blame

[Elijah Lynn]

I've thought about this a bit too. And I like the command `git tell`.

Elijah Lynn
www.elijahlynn.net

On Thu, Mar 2, 2023 at 2:02 PM Dinesh Dharmawardena
<dinesh_dh@outlook.com> wrote:
>
> Hi
>
> 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.
>
> Cheers
> Dinesh
>
> Sent from my iPhone