Thread (1 message) 1 message, 1 author, 2022-07-11

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

From: Junio C Hamano <hidden>
Date: 2022-07-11 19:21:24

Ævar Arnfjörð Bjarmason [off-list ref] writes:
On Sun, Jul 10 2022, Junio C Hamano wrote:
quoted
Michal Suchánek [off-list ref] writes:
quoted
quoted
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/ (local)
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help