Add a build option to skip linking all those built-ins to their dashed form

[dscho]

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.

[periperidip]

Hey dscho,
I am not able to wrap my head around this. The problem is that the "dashed" forms are called in as well for command like git add right( i.e. commands whose dashed forms exist?). And our goal is to prevent that from happening by adding a build option which skips those "dashed" built-ins as far as my understanding goes?

EDIT: I tried to comment out BUILTIN_OBJS += builtin/add.o from the Makefile just to see where it would lead me too. I ran into builtin.h and discovered how a command is added in git. So would going back reverse of that process and cancelling out all the references of the dashed command in all of git would solve the problem?

[dscho]

The problem is that the "dashed" forms are called in as well for command like git add right( i.e. commands whose dashed forms exist?).

To be more precise: in addition to calling git add, you can also call git-add when scripting a new git-<command>. The latter form is deprecated for quite a while now, nevertheless we still hard-link git to git-add in <prefix>/libexec/git-core/.

That is, if your Git executable lives in /usr/bin/git, then it is also hard-linked to /usr/libexec/git-core/git-add (and likewise a ton of other built-in commands).

BTW "built-in" means that the command is implemented directly inside the git executable, not just that it is implemented in C. For example, git-remote-https is implemented in C, but definitely is a separate executable that is spawned from git, by design.

Now, build Git's source code via make you probably saw this insanely long list of BUILTIN <command> at the end, right? That's the hard-linking stage.

Since those "dashed" forms are both unnecessary as well as deprecated, it would be a pretty okay thing to optionally skip that hard-linking stage altogether.

Having said all this, have you noticed that I already opened a "Work-in-Progress" Pull Request, as noted above?

[periperidip]

I appreciate your reply, I have understood it for the most part.
I noticed the "Work-in-Progress" PR just now. I wanted to ask you what work is still left to do in this issue? And direction should I proceed in now?
I noticed that you were trying to add some lists and maybe an option called ALL_PROGRAMS_AND_BUILT_INS. Is that the direction we go in?

[dscho]

what work is still left to do in this issue?

See #411 (comment)

you were trying to add some lists and maybe an option called ALL_PROGRAMS_AND_BUILT_INS.

It's not really a list, it is a variable that concatenates two lists... But yes, I think that this is the correct direction to go. Unless you find a better way, that is.

[phil-blain]

See also: #840

@dscho I guess we can close this here issue, right?

[dscho]

See also: #840

@dscho I guess we can close this here issue, right?

I suppose :-)