Removing the blame command itself is a fairly small amount of work, the hard part is getting community buy-in and making the transition work. The largest issue is breaking the interface to existing scripting which uses blame.
While it's easy enough to restore that functionality for whoever needs it using git alias, doing so system-wide in many systems would still be a massive disruption.
However! There's precedent in git already for admonishments when using deprecated, or to-be-deprecated functionality (like relying on default pull behaviour). Perhaps a first step would be drafting language for and publishing a patch to provide a message when a user types git blame, to suggest the alternative annotate (or introduced alternate) and frame the user's experience better?
From mental health & arts to software engineer in under a year. Passionate about tech for good. Will inevitably end up writing about how coding makes me feel too…
If C was in my language repertoire, I'd be patching away!
"The user discussion and development of Git take place on the Git mailing list -- everyone is welcome to post bug reports, feature requests, comments and patches to git@vger.kernel.org (read Documentation/SubmittingPatches for instructions on patch submission)."
Do you think a feature request or bug report is a good place to start?
I was also thinking that Github could play a role in this. All that would be required on their part is making a tiny UI change, which would help spur momentum. They're certainly branding themselves as a super inclusive company, so in theory they might be amenable?
I know GitLab has done this before, then reverted back to blame. This link has details and a very interesting discussion: gitlab.com/gitlab-org/gitlab/-/iss...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Removing the
blamecommand itself is a fairly small amount of work, the hard part is getting community buy-in and making the transition work. The largest issue is breaking the interface to existing scripting which usesblame.While it's easy enough to restore that functionality for whoever needs it using
git alias, doing so system-wide in many systems would still be a massive disruption.However! There's precedent in git already for admonishments when using deprecated, or to-be-deprecated functionality (like relying on default
pullbehaviour). Perhaps a first step would be drafting language for and publishing a patch to provide a message when a user typesgit blame, to suggest the alternativeannotate(or introduced alternate) and frame the user's experience better?If C was in my language repertoire, I'd be patching away!
"The user discussion and development of Git take place on the Git mailing list -- everyone is welcome to post bug reports, feature requests, comments and patches to git@vger.kernel.org (read Documentation/SubmittingPatches for instructions on patch submission)."
Do you think a feature request or bug report is a good place to start?
I was also thinking that Github could play a role in this. All that would be required on their part is making a tiny UI change, which would help spur momentum. They're certainly branding themselves as a super inclusive company, so in theory they might be amenable?
I know GitLab has done this before, then reverted back to blame. This link has details and a very interesting discussion: gitlab.com/gitlab-org/gitlab/-/iss...