* Re: [GSoC] Doubts in an issue
@ 2020-01-28 10:02 abhishek kumar
2020-01-30 11:30 ` Johannes Schindelin
0 siblings, 1 reply; 3+ messages in thread
From: abhishek kumar @ 2020-01-28 10:02 UTC (permalink / raw)
To: shouryashukla.oo; +Cc: git, gitster, johannes.schindelin
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [GSoC] Doubts in an issue
2020-01-28 10:02 [GSoC] Doubts in an issue abhishek kumar
@ 2020-01-30 11:30 ` Johannes Schindelin
0 siblings, 0 replies; 3+ messages in thread
From: Johannes Schindelin @ 2020-01-30 11:30 UTC (permalink / raw)
To: abhishek kumar; +Cc: shouryashukla.oo, git, gitster
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
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* [GSoC] Doubts in an issue
@ 2020-01-28 2:08 Shourya Shukla
0 siblings, 0 replies; 3+ messages in thread
From: Shourya Shukla @ 2020-01-28 2:08 UTC (permalink / raw)
To: johannes.schindelin; +Cc: gitster, git, 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-01-30 11:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-28 10:02 [GSoC] Doubts in an issue abhishek kumar
2020-01-30 11:30 ` Johannes Schindelin
-- strict thread matches above, loose matches on Subject: below --
2020-01-28 2:08 Shourya Shukla
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).