Hi,
On Tue, 28 Jan 2020, abhishek kumar wrote:
> Greetings Shourya
Show 11 quoted lines
> 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/`.
Show 15 quoted lines
> > 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
Show 8 quoted lines
> 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
>
abhishek kumar