> 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. Perfect, I'll move forward with `clone.defaultRemoteName`. Thanks for the recommendation. This would be the first config variable inside the a "clone" subsection -- is there anything special that needs to happen when a new subsection is added? >>>> ... 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. Agreed - I'm sorry for not including those tests. They'll be present in v2. I'll be sure to include some validation for `clone.defaultRemoteName` within `git_config` as well. > It is somewhat sad that we have the git_config(git_default_config) > call so late in the control flow. I wonder if we can update the > start-up sequence to match the usual flow > ... > One oddity "git clone" has is that it wants to delay the reading of > configuration files (they are read only once, and second and > subsequent git_config() calls will reuse what was read before [*]) so > that it can read what clone.c::write_config() wrote, so if we were to > "fix" the start-up sequence to match the usual flow, we need to > satisfy what that odd arrangement wanted to achieve in some other way > (e.g. feed what is in option_config to git_default_config ourselves, > without using git_config(), as part of the "main control flow uses the > variable" part), but it should be doable. Sounds like a pretty big change! I'm willing to take a crack at it, but given that this is my first patch I'm frankly a bit intimidated :) How would you feel about that being a separate patch? Thanks for all the guidance, folks. Sean
