Description
Once upon a time, in a galaxy far, far away, a Git version still was developed under the impression that it should consist of little Unix tools that are cobbled together by Unix shell scripts. In those olden days, all of those tools lived in the PATH, using names that all started with git- and it was a great hodge podge that Unix graybeards were prone to love: almost a hundred executables cluttering the tab completion (at which Unix graybeards sneer regularly), spawned processes galore.
Fast forward into a more modern time, Git has almost no Unix script parts left, and many, many built-in commands. Those are commands that are contained in the git executable, can be called as git <command> instead of the "dashed" form git-command, and avoid at least one extra spawned process that way.
For hysterical historical reasons, even if there is pretty much no need whatsoever anymore to have, say, git-add in the libexec/git-core/ directory, we do still hardlink all of those built-ins to the corresponding "dashed form", just so that any old script that still expects, say, git-read-tree to be in its PATH (when calling scripts whose name are of the form git-<script-name> via git <script-name>, the git executable will take pains to prepend the libexec/git-core/ directory to the PATH), when in reality it should call git read-tree instead, i.e. the "undashed" form.
It does take quite a while to link all those built-ins during a build, especially on Windows, where the make process uses a POSIX emulation layer (i.e. the MSYS2 runtime, a slightly modified Cygwin runtime), which takes quite some time.
The Git maintainer indicated that they would be fine with a build-time option to not link those built-ins. Eventually, this option should probably become the default.