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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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.