Suggestion to rename "blame" of the "git blame" command to something more neutral

Suggestion to rename "blame" of the "git blame" command to something more neutral

[Jonas Aschenbrenner]

Similar to the change of the default branch name from "master" to
"main" to use a word which has less negative associations,
I suggest to replace the word "blame" with something more neutral.
Maybe "annotate". That word seems to already be used at some places
for this Git feature.

Best regards
Jonas

Re: Suggestion to rename "blame" of the "git blame" command to something more neutral

[Michal Suchánek]

On Thu, Jul 07, 2022 at 05:35:41PM +0200, Jonas Aschenbrenner wrote:
> Similar to the change of the default branch name from "master" to
> "main" to use a word which has less negative associations,
> I suggest to replace the word "blame" with something more neutral.
> Maybe "annotate". That word seems to already be used at some places
> for this Git feature.

Have you seen git-annotate(1)

Best regards

Michal

Re: Suggestion to rename "blame" of the "git blame" command to something more neutral

[Jonas Aschenbrenner]

Thanks. I wasn't  aware of the fact that there is a "git annotate"
command before.
The point regarding the word "blame" seems to remain.
Maybe the "git blame" command can be removed in a future major version
and a flag added to "git annotate" so that "git annotate" can return
the data in the format in which "git blame" currently returns it.

On Thu, Jul 7, 2022 at 7:00 PM Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Thu, Jul 07, 2022 at 05:35:41PM +0200, Jonas Aschenbrenner wrote:
> > Similar to the change of the default branch name from "master" to
> > "main" to use a word which has less negative associations,
> > I suggest to replace the word "blame" with something more neutral.
> > Maybe "annotate". That word seems to already be used at some places
> > for this Git feature.
>
> Have you seen git-annotate(1)
>
> Best regards
>
> Michal

Re: Suggestion to rename "blame" of the "git blame" command to something more neutral

[Junio C Hamano]

Jonas Aschenbrenner <jonas.aschenbrenner@gmail.com> writes:

> Similar to the change of the default branch name from "master" to
> "main" to use a word which has less negative associations,
> I suggest to replace the word "blame" with something more neutral.
> Maybe "annotate". That word seems to already be used at some places
> for this Git feature.

We can help you to match the tool for your personal preference, e.g.

    $ git config --global alias.praise blame
    $ git praise COPYING

Changing what has been known for one name for a long time for other
people takes a lot more than "I do not like the word with negative
connotations".

Re: Suggestion to rename "blame" of the "git blame" command to something more neutral

[Reto]

I like blame... Some humour when using tools is appreciated.
After all, chances are that the idiot who wrote the code was past-you
anyhow :P

Also pretty easy to remember, annotated doesn't exactly strike me as
memorable.

Re: Suggestion to rename "blame" of the "git blame" command to something more neutral

[Ævar Arnfjörð Bjarmason]

On Thu, Jul 07 2022, Jonas Aschenbrenner wrote:

> Similar to the change of the default branch name from "master" to
> "main" to use a word which has less negative associations,
> I suggest to replace the word "blame" with something more neutral.
> Maybe "annotate". That word seems to already be used at some places
> for this Git feature.

What do you think about this old patch of mine to add a 'git praise'?:
https://lore.kernel.org/git/20190401101246.21418-1-avarab@gmail.com/

Re: Suggestion to rename "blame" of the "git blame" command to something more neutral

[Michal Suchánek]

Hello,

On Sun, Jul 10, 2022 at 04:31:18PM +0200, Ævar Arnfjörð Bjarmason wrote:
> 
> On Thu, Jul 07 2022, Jonas Aschenbrenner wrote:
> 
> > Similar to the change of the default branch name from "master" to
> > "main" to use a word which has less negative associations,
> > I suggest to replace the word "blame" with something more neutral.
> > Maybe "annotate". That word seems to already be used at some places
> > for this Git feature.
> 
> What do you think about this old patch of mine to add a 'git praise'?:
> https://lore.kernel.org/git/20190401101246.21418-1-avarab@gmail.com/

Since you are asking .. I think it completely misses the point.

I would consider it effective if users of git-praise(1) needed no
knowledge of existence of git-blame(1).

Thanks

Michal

Re: Suggestion to rename "blame" of the "git blame" command to something more neutral

[Junio C Hamano]

Michal Suchánek <msuchanek@suse.de> writes:

>> What do you think about this old patch of mine to add a 'git praise'?:
>> https://lore.kernel.org/git/20190401101246.21418-1-avarab@gmail.com/
>
> Since you are asking .. I think it completely misses the point.
>
> I would consider it effective if users of git-praise(1) needed no
> knowledge of existence of git-blame(1).

I think you are the one who completely misses the point of him
sending the URL (hint: what is the date of the patch?)

"blame" is perfectly fine.  It is the tool we use to find a commit
or a series of commits to be blamed for whichever blocks of code in
the current codebase we are interested in.  Even if it is to find
the source of the buggy or ugly code in the current codebase
(i.e. "verb with negative connotation"), we are trying to put our
fingers on the commit to be blamed.

And it is not personal---you may find who the "author" was as a side
effect of finding that offending commit, but authors write both good
and bad commits, and what we are trying to find is in which commit
lies the origin of the current badness.  There is no need to be
overly politically correct by bending the verb we use.

Please do not waste our limited engineering resource on a nonsense
like this.  A solution for whoever do not want to type b l a m e has
already been provided upthread and the discussion should end right
there.

Thanks.

Re: Suggestion to rename "blame" of the "git blame" command to something more neutral

[Michal Suchánek]

On Sun, Jul 10, 2022 at 09:35:43AM -0700, Junio C Hamano wrote:
> Michal Suchánek <msuchanek@suse.de> writes:
> 
> >> What do you think about this old patch of mine to add a 'git praise'?:
> >> https://lore.kernel.org/git/20190401101246.21418-1-avarab@gmail.com/
> >
> > Since you are asking .. I think it completely misses the point.
> >
> > I would consider it effective if users of git-praise(1) needed no
> > knowledge of existence of git-blame(1).
> 
> I think you are the one who completely misses the point of him
> sending the URL (hint: what is the date of the patch?)
> 
> "blame" is perfectly fine.  It is the tool we use to find a commit
> or a series of commits to be blamed for whichever blocks of code in
> the current codebase we are interested in.  Even if it is to find
> the source of the buggy or ugly code in the current codebase
> (i.e. "verb with negative connotation"), we are trying to put our
> fingers on the commit to be blamed.

If the word 'blame' is considered offensive by some pople a solution
which basically adds an alias for the blame command without eliminating
the offensive word is insufficient.

Sure, you may not find the word 'blame' offensive. I don't find it
offensive either. I don't find the word 'master' offensive either, and
it was changed anyway.

I don't want to decide whose offense is considered relevant and whose is
disregarded.

It's completely feasible to provide sound solution to eliminating the
word 'blame' from the git source with the exception of some
comaptibility alias, and the linked patch is not it.

Best regards

Michal

RE: Suggestion to rename "blame" of the "git blame" command to something more neutral

[rsbecker]

On July 10, 2022 2:02 PM, Michal Suchánek wrote:
>On Sun, Jul 10, 2022 at 09:35:43AM -0700, Junio C Hamano wrote:
>> Michal Suchánek <msuchanek@suse.de> writes:
>>
>> >> What do you think about this old patch of mine to add a 'git praise'?:
>> >> https://lore.kernel.org/git/20190401101246.21418-1-avarab@gmail.com
>> >> /
>> >
>> > Since you are asking .. I think it completely misses the point.
>> >
>> > I would consider it effective if users of git-praise(1) needed no
>> > knowledge of existence of git-blame(1).
>>
>> I think you are the one who completely misses the point of him sending
>> the URL (hint: what is the date of the patch?)
>>
>> "blame" is perfectly fine.  It is the tool we use to find a commit or
>> a series of commits to be blamed for whichever blocks of code in the
>> current codebase we are interested in.  Even if it is to find the
>> source of the buggy or ugly code in the current codebase (i.e. "verb
>> with negative connotation"), we are trying to put our fingers on the
>> commit to be blamed.
>
>If the word 'blame' is considered offensive by some pople a solution which
>basically adds an alias for the blame command without eliminating the
offensive
>word is insufficient.
>
>Sure, you may not find the word 'blame' offensive. I don't find it
offensive either. I
>don't find the word 'master' offensive either, and it was changed anyway.
>
>I don't want to decide whose offense is considered relevant and whose is
>disregarded.
>
>It's completely feasible to provide sound solution to eliminating the word
'blame'
>from the git source with the exception of some comaptibility alias, and the
linked
>patch is not it.

We already have git annotate as an effective alias. Why not use that if you
don't want git blame?
--R.

Re: Suggestion to rename "blame" of the "git blame" command to something more neutral

[Ævar Arnfjörð Bjarmason]

On Sun, Jul 10 2022, Junio C Hamano wrote:

> Michal Suchánek <msuchanek@suse.de> writes:
>
>>> What do you think about this old patch of mine to add a 'git praise'?:
>>> https://lore.kernel.org/git/20190401101246.21418-1-avarab@gmail.com/
>>
>> Since you are asking .. I think it completely misses the point.
>>
>> I would consider it effective if users of git-praise(1) needed no
>> knowledge of existence of git-blame(1).
>
> I think you are the one who completely misses the point of him
> sending the URL (hint: what is the date of the patch?)

I wrote it as a joke, but that was in 2019, and I think at that time the
idea that we needed to do anything about the "master" nomenclature was
equally far-fetched, but here we are.

While I wrote it as an in-joke, I think some version of it might be
something we'd want to integrate, whether that's (optionally?)
advertising git-annotate over git-blame, adding a git-praise or whatever
else.

Clearly some users care enough about this particular thing to keep
showing up with some regularity to point it out.

Personally I think the "git-blame" argument has a lot more weight than
the "master" one. The latter seems to be the result of language zealotry
extending to usage that really doesn't have anything meaningfully to do
with the underlying issue at play (i.e. a US-based political movement
that seems to have had its zenith in 2020).

Whereas I'm pretty sure that "blame" really does mean "blame" in the bad
sense of the word, but "in a good way".

I.e. I tihnk it's part of a history of playful language use deriving
from early hacker circles, *nix command nomanclature etc. The BSDs in
particular have a lot of that (e.g. "daemon" etc.).

Now, I think making a fuzz about this sort of thing is a bit silly, but
on the other hand git's used in a lot of different environments.

Depending on the proposed change adding a "blame" alias (or promoting an
existing one) might be a lot smaller of a change than everything around
"init.defaultBranch", so *shrug*.

In any case, I think anyone interested in pushing this forward (and I'm
not) needs to come up with some patches to move it forward, or explain
in some detail what is/isn't OK about some existing ones (e.g. my April
1st, 2019 "git-praise" patch).

I understand Michal's and Jonas's upthread suggestions as us doing a
s/blame/praise/g or whatever on the codebase. For backwards
compatibility concerns that would be a non-starter.

But users "having no knowledge of [the other command]" can stop short of
that, and that seems like a good idea in any case. E.g. we have a
long-standing wart of "git stage -h" referring to itself as "git-add",
and "annotate" has the same issue.

There's really no reason we shouldn't fix that, i.e. if we have an alias
and a user uses it, we should at least refer back to it consistently
when we talk about the command the user invoked.

Re: Suggestion to rename "blame" of the "git blame" command to something more neutral

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Sun, Jul 10 2022, Junio C Hamano wrote:
>
>> Michal Suchánek <msuchanek@suse.de> writes:
>>
>>>> What do you think about this old patch of mine to add a 'git praise'?:
>>>> https://lore.kernel.org/git/20190401101246.21418-1-avarab@gmail.com/
>>>
>>> Since you are asking .. I think it completely misses the point.
>>>
>>> I would consider it effective if users of git-praise(1) needed no
>>> knowledge of existence of git-blame(1).
>>
>> I think you are the one who completely misses the point of him
>> sending the URL (hint: what is the date of the patch?)
>
> I wrote it as a joke, but that was in 2019, and I think at that time the
> idea that we needed to do anything about the "master" nomenclature was
> equally far-fetched, but here we are.

Comparing master/main with blame/anything-else is apples and
oranges, though.

The switch of (not the feature to configure) the default was
palatable only because it benefited even those who did not mind the
continued use of the word 'master', those who found 'main' just as
problematic as 'master', or anybody in between, simply because the
major hosting sites and existing projects were or have already
migrated.  In such an external reality, using 'master' as the
hard-coded default would have forced more people to configure when
they start their project, whether they liked or hated the word
'master' [*1*].

"git blame" is completely different.  Nobody cares if you do not
find a "blame" offensive word [*2*], nobody should care if you typed
"git blame", and nobody should dictate you to stop using "git blame"
nor eradicating "blame" from our source.

Let this thread just stop, please.


[Footnotes]

*1* Admittedly we helped the migration of these people by improving
the auto-detection in "git clone" of what the upstream uses, and
adding the configurability to "git init", so we weren't impartial
bystander who passibly adjusted to the prevailing wind, but we
weren't the only one who were setting the policy and forcing other
folks to adopt it.

*2* After all, if the tool finds an old mistake you made, blaming
the earlier breakage to you, why are you making a big fuss about it?
You already made a mistake in the commit "git blame" found; even if
(figuratively) you are playing the "I must always be right" game,
admitting your past mistake does not make you even more wrong.  It
is what you did in the past, and you can simply acknowledge the fact
and move on, with th easpiration that the next time you would be
more careful.  The world would become a better place and the first
step in that journey is to admit your past mistakes and accept the
blame.