Re: [GSoC] Doubts in an issue

Re: [GSoC] Doubts in an issue

[abhishek kumar]

Greetings Shourya

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.

Therefore, "hardlink built-in to the corresponding dashed forms" is to
create a hard link with the dashed form name to the C program.

> 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 :).

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

Re: [GSoC] Doubts in an issue

[Johannes Schindelin]

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
>

[GSoC] Doubts in an issue

[Shourya Shukla]

Greetings Johannes!

I was trying to solve isse #406[1]. I have understood what we are trying to achieve for
the most part, but I still need some confirmation. As far as my understanding goes, here
is what I have inferred(forgive me if I am wrong anywhere):

We had "dashed" versions of present day commands such as <<git add>> in the old times.
Now, whenever we call scripts whose "dashed" version exists, it will sort of link the "dashed"
version as well for I guess historical reasons? ;)

And hence this takes up quite some time to link those built-ins especially in Windows. Therefore,
our aim is to remove that option of linking the "dashed" forms by default.

One thing I don't understand is, where is the <<libexec/git-core/>> directory? And what exactly
do we mean by "built-ins" here(does it refer to the "dashed" commands)?

Thanks, 
Shourya Shukla

[1]: https://github.com/gitgitgadget/git/issues/406