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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 11, 2022, 11:47 UTC
Message-ID: <220711.86sfn77sd7.gmgdl@evledraar.gmail.com>
In-Reply-To: <xmqq1qutrkm8.fsf@gitster.g>

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

Show 12 quoted lines

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