{"thread":{"id":"52707","subject":"Re: [GSoC] Doubts in an issue","startedAt":"2020-01-28T10:02:54Z","lastAt":"2020-01-30T11:30:23Z","messageCount":2,"participants":["abhishek kumar","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"390619","messageId":"CAHk66fs+FX_W+MwOCOF1_zw_vPz73D+0HbTrb7sXTHzgnWhzQQ@mail.gmail.com","threadId":"52707","inReplyTo":null,"subject":"Re: [GSoC] Doubts in an issue","fromName":"abhishek kumar","fromEmail":"abhishekkumar8222@gmail.com","sentAt":"2020-01-28T10:02:06Z","receivedAt":"2020-01-28T10:02:54Z","isPatch":false,"sender":{"key":"abhishekkumar8222@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31231064?v=4"},"body":"Greetings Shourya\n\nI am not exactly Johannes (just another GSoC applicant) but here's\nwhat I understood from the issue and your thread:\n\n> And what exactly do we mean by \"built-ins\" here(does it refer to the \"dashed\" commands)?\n\n\"Built-in\" refers to commands implemented in C [1][2]. The more common\nuse of \"built-in\" which is a command that the shell (bash, sh, ksh)\ncarries out itself [3]. The name draws out the similarity between\nshell builtins and git builtins, both written in C and executable\nthrough the shell.\n\nTherefore, \"hardlink built-in to the corresponding dashed forms\" is to\ncreate a hard link with the dashed form name to the C program.\n\n> where is the <<libexec/git-core/>> directory?\n\nAs the makefile suggests, the programs and scripts are installed at\n`gitexecdir`. I couldn't find it but instead found `GIT_EXEC_PATH`\nwhich point to pretty much the same thing. You can find it by `git\n--exec_path` [4].\n\n> Now, whenever we call scripts whose \"dashed\" version exists, it will sort of link the \"dashed\" version as well for I guess historical reasons? ;)\n\nNo. Creating hard links is done during the build process. But calling\n`git-<script-name>` through `git <script-name>` makes `git` prepend\n`libexec/gitcore` which is necessary to find the hard link. So, you\nare half-right :).\n\nRegards\nAbhishek\n\n[1]: https://github.com/msysgit/msysgit/wiki/Why-Is--libexec--so-huge%3F\n[2]: https://github.com/git/git/blob/master/builtin.h\n[3]: https://unix.stackexchange.com/a/11465\n[4]: https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables\n"},{"id":"390784","messageId":"nycvar.QRO.7.76.6.2001301210410.46@tvgsbejvaqbjf.bet","threadId":"52707","inReplyTo":"CAHk66fs+FX_W+MwOCOF1_zw_vPz73D+0HbTrb7sXTHzgnWhzQQ@mail.gmail.com","subject":"Re: [GSoC] Doubts in an issue","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-01-30T11:30:17Z","receivedAt":"2020-01-30T11:30:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 28 Jan 2020, abhishek kumar wrote:\n\n> Greetings Shourya\n\nThanks for jumping in!\n\n> I am not exactly Johannes (just another GSoC applicant) but here's what\n> I understood from the issue and your thread:\n>\n> > And what exactly do we mean by \"built-ins\" here(does it refer to the\n> > \"dashed\" commands)?\n>\n> \"Built-in\" refers to commands implemented in C [1][2]. The more common\n> use of \"built-in\" which is a command that the shell (bash, sh, ksh)\n> carries out itself [3]. The name draws out the similarity between shell\n> builtins and git builtins, both written in C and executable through the\n> shell.\n\nIt is _slightly_ more complicated than that. There are Git commands that\nare implemented in C and that are _not_ built-ins, for example `git\nfast-import` or `git remote-https`. The reasons are sometimes historical,\nsometimes not so (for example, we keep `remote-https` separate to avoid\nthe startup cost of linking libcurl for _every_ `git` invocation).\n\nBut yes, the built-in commands are the ones covered by the `git`\nexecutable, i.e. `git` does not have to spawn another executable or script\nto perform the command.\n\n> Therefore, \"hardlink built-in to the corresponding dashed forms\" is to\n> create a hard link with the dashed form name to the C program.\n\nRight. For historical context, the \"dashed form\" was originally the only\nform: commands like `git show` were implemented in scripts/executables\nwhose name was `git-show`. Eventually the number of such\nscripts/executables got too ridiculous to leave in the `PATH`, so they\nwere squirreled away into the `<prefix>/libexec/git-core/` directory. So\nif your `git` executable lives in `/usr/local/bin/git`, those\nscripts/executables would live in `/usr/local/libexec/git-core/`.\n\nAt some point, we started to consolidate most of the commands that were\n_already_ implemented in C into the set of built-ins. Meaning that the\n`git` executable would first figure out under which name it was called,\nand then perform the appropriate function.\n\nThis allowed us to hard-link `git` to, say, `git-show` and not waste disk\nspace.\n\nAt some point we had so many built-ins that the \"dashed form\" was\ndeprecated. It _already_ only worked in scripted sub-commands (you can\nimplement your own Git subcommand by implemeting a script whose name\nstarts with `git-` and then putting it into the `PATH`, for example\n`git-cinnabar` would be picked up by `git cinnabar` and would\nautomatically append the `libexec/git-core/` directory to the `PATH`\nbefore running that script) unless you added the libexec directory to your\n`PATH` explicitly.\n\nFrom that point on, we encouraged power users who automate their workflow\nvia shell scripts to use `git rev-list` instead of `git-rev-list` in their\nscripts.\n\nThis has been going on for _quite_ a while, so at this point it should be\nsafe to stop hard-linking those built-ins. It should be enough that the\n`git` executable knows how to run the program, there does not really need\nto be a hardlink in `libexec/git-core/`.\n\n> > where is the <<libexec/git-core/>> directory?\n>\n> As the makefile suggests, the programs and scripts are installed at\n> `gitexecdir`. I couldn't find it but instead found `GIT_EXEC_PATH`\n> which point to pretty much the same thing. You can find it by `git\n> --exec_path` [4].\n>\n> > Now, whenever we call scripts whose \"dashed\" version exists, it will\n> > sort of link the \"dashed\" version as well for I guess historical\n> > reasons? ;)\n>\n> No. Creating hard links is done during the build process. But calling\n> `git-<script-name>` through `git <script-name>` makes `git` prepend\n> `libexec/gitcore` which is necessary to find the hard link. So, you\n> are half-right :).\n\nTo add to this, I already had provided a head-start in\nhttps://github.com/gitgitgadget/git/pull/411...\n\nShourya, if you want to complete it, be my guest. I left a comment what\nstill needs to be done. If in doubt, just ping me in the ticket (or if I\nam slow, ask for help on this here mailing list).\n\nCiao,\nJohannes\n\n> Regards\n> Abhishek\n>\n> [1]: https://github.com/msysgit/msysgit/wiki/Why-Is--libexec--so-huge%3F\n> [2]: https://github.com/git/git/blob/master/builtin.h\n> [3]: https://unix.stackexchange.com/a/11465\n> [4]: https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables\n>\n"}]}