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. [References] *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/
