Re: [PATCH v2 0/2] avoid running "git-subcmd" in the dashed form
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 27, 2020, 01:22 UTC
- Message-ID
- <xmqqy2m0swzz.fsf@gitster.c.googlers.com>
- In-Reply-To
- <07f26226-c1cd-494d-899e-d6452ad2751f@gmail.com>
Derrick Stolee <stolee@gmail.com> writes:
> Would an interesting in-between step include removing the dashed > forms for builtins that didn't exist in Git 2.0?
I am not sure if it makes much sense to treat newer and older built-in commands differently.
Imagine that an old-timer wrote a script by somebody who trusted the "futz with PATH and you can use git-foo" promise before Git 2.0 and then the script was inherited by relatively new users. Adhering to the "when in doubt, mimic the surrounding code", which is usually a good discipline to follow, these new users, who are now in charge of maintaining the script, would add any new calls in "git-foo" form to match the local convention in good faith. And the resulting code would have been working just fine.
Before such a "in-between step" is thrown at them, that is, at which point it stops working if they were unlucky that they used a relatively new built-ins. Typically new end-users would not know which ones are old built-ins and which ones are new, I suspect.
I do agree with Dscho that "we won't let you use builtin in dashed form before you export an enviornment" I wrote was not a good way to gauge the usage of on-disk builtins. We should move the on-disk builtins to a different directory and have them point at the location with their $PATH as the escape hatch, as Dscho suggested, if we were to do this for real, I'd think.
Thanks.