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

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

On Thu, Jul 07, 2022 at 05:35:41PM +0200, Jonas Aschenbrenner wrote:

Have you seen git-annotate(1)

Best regards

Michal

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:

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

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

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.

On Thu, Jul 07 2022, Jonas Aschenbrenner wrote:

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/

Hello,

On Sun, Jul 10, 2022 at 04:31:18PM +0200, Ævar Arnfjörð Bjarmason wrote:

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

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

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.

On Sun, Jul 10, 2022 at 09:35:43AM -0700, Junio C Hamano wrote:

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

On July 10, 2022 2:02 PM, Michal Suchánek wrote:

offensive

offensive either. I

'blame'

linked

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

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

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.

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

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.