Because the joke doesn’t land if typing “git gud” doesn’t actually do something.

To your point, I would say that it’s “easy” rather than strictly helpful. There is a plugin I maintain internally that can be invoked by calling “helm <thing>” if I go through the necessary steps to have it installable by the helm plugin command. Under the hood it’s just a small binary that you can put in your $PATH and it’ll work fine, but there are tons of developers and PMs and other people at the company who don’t know what a path variable is, or how to set it, or what a terminal is, or what shell they’re running, or who know that they can do “helm X” and “helm Y”, so why not “helm Z” for my plugin, etc … It would be a hell of a lot easier to just ship the raw executable, but to those people and execs and mangers and stuff, it looks good if I can show it off next to the native stuff.

Whenever I have to help users with it, I notice that nearly everyone uses it with helm and not calling by the binary directly. It just comes down to the fact that presentation and perceived ease of use counts for a lot when people evaluate whether they want to make a tool part of their workflow.

Git itself uses this functionality. On my ubuntu system the path is `/usr/lib/git-core/` and in it you see all sorts of bins for "git commands", e.g `git-rm`, `git-mv`, `git-difftool`, etc. A lot of these are just links back to the git binary these days, but many features begin life as a standalone `git-$X` executable, and back in early git days much more functionality was split across executables. (The ones that are now links back to git are largely for scripting purposes, a lot of git "plugins" and various CI type scripts will call `git-mv` rather than trying to get quoting right around calling `git mv` for example.

It also helps make plugins easier to distribute. I don't want to have to type `git-x` sometimes and `git y` others, and if I want my plugin to get adoption, I really really don't want that. So things like git-lfs, git-annex, etc can easily be distributed, documented as a plugin, and generally be considered as "a part of git", rather than a separate command.

This pattern is also not unique to git. Other softwares have followed it, notably cargo.

It allows things to be added and removed from the main executable without changing the interface. This means if someone has a good idea everyone starts using, and they implemented it as a subcommand like this, it could eventually be integrated into git without anyone having to migrate. Also all the subcommands are implemented as separate executables like this anyway.

For example in /usr/lib/git-core/ with git 2.25.1 on Ubuntu, "git-rebase" is a symlink to "git". But on an older Centos VM I have access to, in /usr/libexec/git-core/ with git 2.16.5, "git-rebase" is a separate shell script.

Because if it's part of the repo, you don't depend on the host to take the extra step, which, if you're working from ephemeral instances or places where that step would have to be repeated, is a god send

Because it's thematically a part of a git workflow.

Because something might make less sense on its own or conflict with another tool.