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@xxxxxxx> 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@xxxxxxxxx >> >> / >> > >> > 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.
