Re: [PATCH v4 9/9] checkout & worktree: introduce checkout.defaultRemote

> Hi Ævar,
>
> Sorry for chiming in late. I have a couple of thoughts:
>
>>     (
>>         cd /tmp &&
>>         rm -rf tbdiff &&
>>         git clone git@github.com:trast/tbdiff.git &&
>>         cd tbdiff &&
>>         git branch -m topic &&
>>         git checkout master
>>     )
>>
>> That will output:
>>
>>     Branch 'master' set up to track remote branch 'master' from 'origin'.
>>     Switched to a new branch 'master'
>
> I thought master is already there after the clone operation and
> you'd merely switch back to the local branch that was created at
> clone time?
>
>     $ git clone git@github.com:trast/tbdiff.git && cd tbdiff
>     $ git branch
>     * master
>     $ cat .git/config
> ...
> [branch "master"]
>     remote = origin
>     merge = refs/heads/master
>
> But the observation is right, we get that message. When do we
> do the setup for the master branch specifically?

>>
>> But as soon as a new remote is added (e.g. just to inspect something
>> from someone else) the DWIMery goes away:
>>
>>     (
>>         cd /tmp &&
>>         rm -rf tbdiff &&
>>         git clone git@github.com:trast/tbdiff.git &&
>>         cd tbdiff &&
>>         git branch -m topic &&
>>         git remote add avar git@github.com:avar/tbdiff.git &&
>>         git fetch avar &&
>>         git checkout master
>>     )
>>
>> Will output (without the advice output added earlier in this series):
>>
>>     error: pathspec 'master' did not match any file(s) known to git.
>>
>> The new checkout.defaultRemote config allows me to say that whenever
>> that ambiguity comes up I'd like to prefer "origin", and it'll still
>> work as though the only remote I had was "origin".
>>
>> Also adjust the advice.checkoutAmbiguousRemoteBranchName message to
>> mention this new config setting to the user, the full output on my
>> git.git is now (the last paragraph is new):
>>
>>     $ ./git --exec-path=$PWD checkout master
>>     error: pathspec 'master' did not match any file(s) known to git.
>>     hint: The argument 'master' matched more than one remote tracking branch.
>>     hint: We found 26 remotes with a reference that matched. So we fell back
>>     hint: on trying to resolve the argument as a path, but failed there too!
>>     hint:
>>     hint: Perhaps you meant fully qualify the branch name? E.g. origin/<name>
>
> s/meant fully/meant to fully/
> s/? E.g./?\nFor example/

>>     hint: instead of <name>?
>
> In builtin/submodule--helper.c there is get_default_remote() which also
> hardcodes "origin". I think that is a safe thing to do.
>
>>     hint:
>>     hint: If you'd like to always have checkouts of 'master' prefer one remote,
>>     hint: e.g. the 'origin' remote, consider setting checkout.defaultRemote=origin
>>     hint: in your config. See the 'git-config' manual page for details.
>
> his new setting elevates one remote over all others, which may
> be enough for most setups and not confusing, too.
> Consider the following:
>
>     git clone https://kernel.googlesource.com/pub/scm/git/git && cd git
>     git remote add gitster https://github.com/gitster/git
>     git remote add interesting-patches https://github.com/avar/git
>     git remote add my-github https://github.com/stefanbeller/git
>
>     git checkout master
>
> This probably means I want to have origin/master (from kernel.org)
>
>     git checkout ab/checkout-implicit-remote
>
> This probably wants to have it from gitster/ (as it is not found on kernel.org);
> I am not sure if it would want to look at interesting-patches/ that mirrors
> github, but probably if it were not to be found at gitster.
>
> So maybe we rather want a setup to give a defined priority for
> the search order:
>
>   git config dwim.remoteSearchOrder origin gitster avar
>
> Stepping back a bit, there is already an order in the config file
> for the remotes, and that order is used for example for 'fetch --all'.
>
> I wonder if we want to take that order? (Or are the days of hand
> editing the config over and this is too arcane? We would need a
> config command to re order remotes). Then we could just have a
> boolean switch to use the config order on ambiguity.
> Although you might want to have a different order for fetching
> and looking for the right checkout.

>> I considered splitting this into checkout.defaultRemote and
>> worktree.defaultRemote, but it's probably less confusing to break our
>> own rules that anything shared between config should live in core.*
>> than have two config settings, and I couldn't come up with a short
>> name under core.* that made sense (core.defaultRemoteForCheckout?).
>
>   core.dwimRemote ? It's a bit cryptic, though.