* Suggestion to rename "blame" of the "git blame" command to something more neutral @ 2022-07-07 15:35 Jonas Aschenbrenner 2022-07-07 17:00 ` Michal Suchánek ` (3 more replies) 0 siblings, 4 replies; 12+ messages in thread From: Jonas Aschenbrenner @ 2022-07-07 15:35 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Suggestion to rename "blame" of the "git blame" command to something more neutral 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 ` (2 subsequent siblings) 3 siblings, 1 reply; 12+ messages in thread From: Michal Suchánek @ 2022-07-07 17:00 UTC (permalink / raw) To: Jonas Aschenbrenner; +Cc: git On Thu, Jul 07, 2022 at 05:35:41PM +0200, Jonas Aschenbrenner wrote: > 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. Have you seen git-annotate(1) Best regards Michal ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Suggestion to rename "blame" of the "git blame" command to something more neutral 2022-07-07 17:00 ` Michal Suchánek @ 2022-07-07 19:12 ` Jonas Aschenbrenner 0 siblings, 0 replies; 12+ messages in thread From: Jonas Aschenbrenner @ 2022-07-07 19:12 UTC (permalink / raw) To: Michal Suchánek; +Cc: git 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: > > On Thu, Jul 07, 2022 at 05:35:41PM +0200, Jonas Aschenbrenner wrote: > > 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. > > Have you seen git-annotate(1) > > Best regards > > Michal ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Suggestion to rename "blame" of the "git blame" command to something more neutral 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 21:03 ` Junio C Hamano 2022-07-10 13:00 ` Reto 2022-07-10 14:31 ` Ævar Arnfjörð Bjarmason 3 siblings, 0 replies; 12+ messages in thread From: Junio C Hamano @ 2022-07-07 21:03 UTC (permalink / raw) To: Jonas Aschenbrenner; +Cc: git Jonas Aschenbrenner <jonas.aschenbrenner@gmail.com> writes: > 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. 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". ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Suggestion to rename "blame" of the "git blame" command to something more neutral 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 21:03 ` Junio C Hamano @ 2022-07-10 13:00 ` Reto 2022-07-10 14:31 ` Ævar Arnfjörð Bjarmason 3 siblings, 0 replies; 12+ messages in thread From: Reto @ 2022-07-10 13:00 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Suggestion to rename "blame" of the "git blame" command to something more neutral 2022-07-07 15:35 Suggestion to rename "blame" of the "git blame" command to something more neutral Jonas Aschenbrenner ` (2 preceding siblings ...) 2022-07-10 13:00 ` Reto @ 2022-07-10 14:31 ` Ævar Arnfjörð Bjarmason 2022-07-10 14:55 ` Michal Suchánek 3 siblings, 1 reply; 12+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2022-07-10 14:31 UTC (permalink / raw) To: Jonas Aschenbrenner; +Cc: git On Thu, Jul 07 2022, Jonas Aschenbrenner wrote: > 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. 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Suggestion to rename "blame" of the "git blame" command to something more neutral 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 0 siblings, 1 reply; 12+ messages in thread From: Michal Suchánek @ 2022-07-10 14:55 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason; +Cc: Jonas Aschenbrenner, git Hello, On Sun, Jul 10, 2022 at 04:31:18PM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Thu, Jul 07 2022, Jonas Aschenbrenner wrote: > > > 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. > > 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). Thanks Michal ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Suggestion to rename "blame" of the "git blame" command to something more neutral 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-11 11:47 ` Ævar Arnfjörð Bjarmason 0 siblings, 2 replies; 12+ messages in thread From: Junio C Hamano @ 2022-07-10 16:35 UTC (permalink / raw) To: Michal Suchánek Cc: Ævar Arnfjörð Bjarmason, Jonas Aschenbrenner, git 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?) "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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Suggestion to rename "blame" of the "git blame" command to something more neutral 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 1 sibling, 1 reply; 12+ messages in thread From: Michal Suchánek @ 2022-07-10 18:01 UTC (permalink / raw) To: Junio C Hamano Cc: Ævar Arnfjörð Bjarmason, Jonas Aschenbrenner, git On Sun, Jul 10, 2022 at 09:35:43AM -0700, 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?) > > "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. 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Suggestion to rename "blame" of the "git blame" command to something more neutral 2022-07-10 18:01 ` Michal Suchánek @ 2022-07-10 18:26 ` rsbecker 0 siblings, 0 replies; 12+ messages in thread From: rsbecker @ 2022-07-10 18:26 UTC (permalink / raw) To: 'Michal Suchánek', 'Junio C Hamano' Cc: 'Ævar Arnfjörð Bjarmason', 'Jonas Aschenbrenner', git On July 10, 2022 2:02 PM, Michal Suchánek wrote: >On Sun, Jul 10, 2022 at 09:35:43AM -0700, 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?) >> >> "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. > >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. We already have git annotate as an effective alias. Why not use that if you don't want git blame? --R. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Suggestion to rename "blame" of the "git blame" command to something more neutral 2022-07-10 16:35 ` Junio C Hamano 2022-07-10 18:01 ` Michal Suchánek @ 2022-07-11 11:47 ` Ævar Arnfjörð Bjarmason 2022-07-11 19:21 ` Junio C Hamano 1 sibling, 1 reply; 12+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2022-07-11 11:47 UTC (permalink / raw) To: Junio C Hamano; +Cc: Michal Suchánek, Jonas Aschenbrenner, git 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Suggestion to rename "blame" of the "git blame" command to something more neutral 2022-07-11 11:47 ` Ævar Arnfjörð Bjarmason @ 2022-07-11 19:21 ` Junio C Hamano 0 siblings, 0 replies; 12+ messages in thread From: Junio C Hamano @ 2022-07-11 19:21 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: Michal Suchánek, Jonas Aschenbrenner, git Æ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. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-07-11 19:21 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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).