Hi, On Tue, 28 Jan 2020, abhishek kumar wrote: > Greetings Shourya Thanks for jumping in! > I am not exactly Johannes (just another GSoC applicant) but here's what > I understood from the issue and your thread: > > > And what exactly do we mean by "built-ins" here(does it refer to the > > "dashed" commands)? > > "Built-in" refers to commands implemented in C [1][2]. The more common > use of "built-in" which is a command that the shell (bash, sh, ksh) > carries out itself [3]. The name draws out the similarity between shell > builtins and git builtins, both written in C and executable through the > shell. It is _slightly_ more complicated than that. There are Git commands that are implemented in C and that are _not_ built-ins, for example `git fast-import` or `git remote-https`. The reasons are sometimes historical, sometimes not so (for example, we keep `remote-https` separate to avoid the startup cost of linking libcurl for _every_ `git` invocation). But yes, the built-in commands are the ones covered by the `git` executable, i.e. `git` does not have to spawn another executable or script to perform the command. > Therefore, "hardlink built-in to the corresponding dashed forms" is to > create a hard link with the dashed form name to the C program. Right. For historical context, the "dashed form" was originally the only form: commands like `git show` were implemented in scripts/executables whose name was `git-show`. Eventually the number of such scripts/executables got too ridiculous to leave in the `PATH`, so they were squirreled away into the `<prefix>/libexec/git-core/` directory. So if your `git` executable lives in `/usr/local/bin/git`, those scripts/executables would live in `/usr/local/libexec/git-core/`. At some point, we started to consolidate most of the commands that were _already_ implemented in C into the set of built-ins. Meaning that the `git` executable would first figure out under which name it was called, and then perform the appropriate function. This allowed us to hard-link `git` to, say, `git-show` and not waste disk space. At some point we had so many built-ins that the "dashed form" was deprecated. It _already_ only worked in scripted sub-commands (you can implement your own Git subcommand by implemeting a script whose name starts with `git-` and then putting it into the `PATH`, for example `git-cinnabar` would be picked up by `git cinnabar` and would automatically append the `libexec/git-core/` directory to the `PATH` before running that script) unless you added the libexec directory to your `PATH` explicitly. >From that point on, we encouraged power users who automate their workflow via shell scripts to use `git rev-list` instead of `git-rev-list` in their scripts. This has been going on for _quite_ a while, so at this point it should be safe to stop hard-linking those built-ins. It should be enough that the `git` executable knows how to run the program, there does not really need to be a hardlink in `libexec/git-core/`. > > where is the <<libexec/git-core/>> directory? > > As the makefile suggests, the programs and scripts are installed at > `gitexecdir`. I couldn't find it but instead found `GIT_EXEC_PATH` > which point to pretty much the same thing. You can find it by `git > --exec_path` [4]. > > > Now, whenever we call scripts whose "dashed" version exists, it will > > sort of link the "dashed" version as well for I guess historical > > reasons? ;) > > No. Creating hard links is done during the build process. But calling > `git-<script-name>` through `git <script-name>` makes `git` prepend > `libexec/gitcore` which is necessary to find the hard link. So, you > are half-right :). To add to this, I already had provided a head-start in https://github.com/gitgitgadget/git/pull/411... Shourya, if you want to complete it, be my guest. I left a comment what still needs to be done. If in doubt, just ping me in the ticket (or if I am slow, ask for help on this here mailing list). Ciao, Johannes > Regards > Abhishek > > [1]: https://github.com/msysgit/msysgit/wiki/Why-Is--libexec--so-huge%3F > [2]: https://github.com/git/git/blob/master/builtin.h > [3]: https://unix.stackexchange.com/a/11465 > [4]: https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables >
