Web lists-archives.com

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

Junio C Hamano <gitster@xxxxxxxxx> 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.


*1* https://public-inbox.org/git/alpine.LFD.1.10.0808261114070.3363@xxxxxxxxxxxxxxxxxxxxxxxxxxxx/

*2* https://public-inbox.org/git/20080826145719.GB5046@xxxxxxxxxxxxxxxxxxxxxxx/

*3* https://public-inbox.org/git/7vprnzt7d5.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx/