Derrick Stolee <stolee@xxxxxxxxx> writes: > On 8/26/2020 2:46 PM, Junio C Hamano wrote: >> "Sean Barag via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: >>> This commit implements >>> `remote.cloneDefault` as a parallel to `remote.pushDefault`, >>> with prioritized name resolution: >> >> I highly doubt that .cloneDefault is a good name. After reading >> only the title of the patch e-mail, i.e. when the only available >> information on the change available to me was the name of the >> configuration variable and the fact that it pertains to the command >> "git clone", I thought it is to specify a URL, from which "git >> clone" without the URL would clone from that single repository. >> >> And the name will cause the same misunderstanding to normal users, >> not just to reviewers of your patch, after this change hits a future >> Git release. >> >> Taking a parallel from init.defaultBranchName, I would probably call >> it clone.defaultUpstreamName if I were writing this feature. > > I was thinking "clone.defaultRemoteName" makes it clear we are naming > the remote for the provided <url> in the command. I 100% agree that defaultremotename is much better. >> ... For example >> >> git -c remote.cloneDefault="bad.../...name" clone parent >> >> should fail, no? > > This is an important suggestion. To be fair, the current code does not handle the "--origin" command line option not so carefully. Back when the command was scripted, e.g. 47874d6d (revamp git-clone (take #2)., 2006-03-21), had both ref-format check and */* multi-level check, and these checks been retained throughout its life until 8434c2f1 (Build in clone, 2008-04-27) rewrote the whole thing while discarding these checks for --origin=bad.../...name It would make an excellent #leftoverbits or #microproject. Thanks.
