Re: [PATCH] Drop some dashes from built-in invocations in scripts

Junio C Hamano [off-list ref] writes:

Earlier there was a more ambitious proposal to remove all "git-foo"
even from $GIT_EXEC_PATH for built-in commands, but that plan was
scuttled [*1*].

The changes in your patch still are good changes to make sure people
who copy & paste code would see fewer instances of "git-foo", but
"will still work even if I break my installation of Git by removing
them from the filesystem" is not the project's goal.  

IIUC, you will need "$GIT_EXEC_PATH/git-checkout" on the filesystem
if you want your "git co" alias to work, as we spawn built-in as a
dashed external.

Just to avoid possible confusion, the above is not to say "once it
is decided, you are not allowed to bring fresh arguments to the
discussion".  As Peff said [*2*] in that old discussion thread, the
circumstances may have changed over 9 years, and it may benefit to
revisit some old decisions.

So in that sense, I do not mind somebody makes a fresh proposal,
which would probably be similar to what I did back then in [*3*],
which is at the beginning of that old thread.  But I do not think I
would be doing so myself, and I suspect that I would not be very
supportive for such a proposal, because my gut feeling is that the
upside is not big enough compared to downsides.

The obvious upside is that you do not have to have many built-in
commands on the filesystem, either as a hardlink, a copy, or a
symbolic link.  But we will be breaking people's scripts by breaking
the 11-year old promise that we will keep their "git-foo" working as
long as they prepend $GIT_EXEC_PATH to their $PATH we we did so.
Another downside is that we now will expose which subcommands are
built-in and which are not, which is unnecessarily implementation
detail we'd want end-users to rely on.

The "'git co' may stop working" I mentioned in my previous message
is not counted as a downside---if the upside is large enough, I
think that "we respawn git-foo as dashed built-in when running an
alias that expands to 'foo'" can be fixed to respawn "git foo"
instead of "git-foo".  But there may be other downside that we may
not be able to fix, and I suspect that "we'd be breaking the 11-year
old promise" is something we would not be able to fix.  That is why
I doubt that I would be advocating the removal of "git-foo" from the
filesystem myself.


[References]

*1* https://public-inbox.org/git/alpine.LFD.1.10.0808261114070.3363@nehalem.linux-foundation.org/

*2* https://public-inbox.org/git/20080826145719.GB5046@coredump.intra.peff.net/

*3* https://public-inbox.org/git/7vprnzt7d5.fsf@gitster.siamese.dyndns.org/

On 8/7/17, Junio C Hamano [off-list ref] wrote:

Just to avoid possible confusion, the above is not to say "once it
is decided, you are not allowed to bring fresh arguments to the
discussion".  As Peff said [*2*] in that old discussion thread, the
circumstances may have changed over 9 years, and it may benefit to
revisit some old decisions.

So in that sense, I do not mind somebody makes a fresh proposal,
which would probably be similar to what I did back then in [*3*],
which is at the beginning of that old thread.  But I do not think I
would be doing so myself, and I suspect that I would not be very
supportive for such a proposal, because my gut feeling is that the
upside is not big enough compared to downsides.

The obvious upside is that you do not have to have many built-in
commands on the filesystem, either as a hardlink, a copy, or a
symbolic link.  But we will be breaking people's scripts by breaking
the 11-year old promise that we will keep their "git-foo" working as
long as they prepend $GIT_EXEC_PATH to their $PATH we we did so.
Another downside is that we now will expose which subcommands are
built-in and which are not, which is unnecessarily implementation
detail we'd want end-users to rely on.

The "'git co' may stop working" I mentioned in my previous message
is not counted as a downside---if the upside is large enough, I
think that "we respawn git-foo as dashed built-in when running an
alias that expands to 'foo'" can be fixed to respawn "git foo"
instead of "git-foo".  But there may be other downside that we may
not be able to fix, and I suspect that "we'd be breaking the 11-year
old promise" is something we would not be able to fix.  That is why
I doubt that I would be advocating the removal of "git-foo" from the
filesystem myself.

Thanks for the history and explanation, Junio. I agree with your analysis.

I didn't know that git aliases invoke the `git-foo` path for built-ins
(I don't use them much myself, so didn't notice).

I also didn't know that it was supported to add GIT_EXEC_DIR to your
PATH to be able to call `git-foo`. I generally think of /libexec as
implementation-specific executables that a tool may call internally
(in that sense, whether or not the commands are built-ins would remain
an implementation-detail).

However, I still think the patch should be applied for
self-consistency at least (git-submodule.sh currently calls both `git
rev-parse` and `git-rev-parse`). Also, based on Johannes' reply, it
may still be useful for git-for-windows.

[References]

*1*
https://public-inbox.org/git/alpine.LFD.1.10.0808261114070.3363@nehalem.linux-foundation.org/

*2*
https://public-inbox.org/git/20080826145719.GB5046@coredump.intra.peff.net/

*3* https://public-inbox.org/git/7vprnzt7d5.fsf@gitster.siamese.dyndns.org/