From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "Michal Suchánek" <msuchanek@suse.de>,
"Jonas Aschenbrenner" <jonas.aschenbrenner@gmail.com>,
git@vger.kernel.org
Subject: Re: Suggestion to rename "blame" of the "git blame" command to something more neutral
Date: Mon, 11 Jul 2022 12:21:16 -0700 [thread overview]
Message-ID: <xmqqwncjo3pv.fsf@gitster.g> (raw)
In-Reply-To: <220711.86sfn77sd7.gmgdl@evledraar.gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Mon, 11 Jul 2022 13:47:06 +0200")
Æ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.
prev parent reply other threads:[~2022-07-11 19:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-07 15:35 Suggestion to rename "blame" of the "git blame" command to something more neutral Jonas Aschenbrenner
2022-07-07 17:00 ` Michal Suchánek
2022-07-07 19:12 ` Jonas Aschenbrenner
2022-07-07 21:03 ` Junio C Hamano
2022-07-10 13:00 ` Reto
2022-07-10 14:31 ` Ævar Arnfjörð Bjarmason
2022-07-10 14:55 ` Michal Suchánek
2022-07-10 16:35 ` Junio C Hamano
2022-07-10 18:01 ` Michal Suchánek
2022-07-10 18:26 ` rsbecker
2022-07-11 11:47 ` Ævar Arnfjörð Bjarmason
2022-07-11 19:21 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqwncjo3pv.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=jonas.aschenbrenner@gmail.com \
--cc=msuchanek@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).