Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > +checkout.implicitRemote:: > + When you run 'git checkout <something>' and only have one > + remote, it may implicitly fall back on checking out and > + tracking e.g. 'origin/<something>'.
Yup, that is quite implicit. It works without configuring anything, only as long as you have a single remote. That is quite implicit. > This stops working as soon > + as you have more than one remote with a '<something>' > + reference. This setting allows for setting the name of a > + preferred remote that should always win when it comes to > + disambiguation. The typical use-case is to set this to > + `origin`. So this feature and configuration feels more like an explicit one, to be used to affect how Git works when the implicit one does not work well. I would have called it checkout.defaultRemote, as it would be a nonsense name to call it checkout.explicitRemote ;-). > +Currently this is used by linkgit:git-checkout[1] when 'git checkout > +<something>' will checkout the '<something>' branch on another remote, > +and by linkgit:git-worktree[1] when 'git worktree add' refers to a > +remote branch. This setting might be used for other checkout-like > +commands or functionality in the future. Hmph, that is an interesting direction. You foresee that you'll have a single repository with multiple remotes to grab and share objects from different people working on the same project, and use multiple worktrees to work on different branches, yet you are happy to declare that each worktree is to work with one particular remote? We'd need a per-worktree config file to make it work, I guess, or a three-level checkout.$worktree_id.defaultRemote configuration variable, perhaps? In any case I can see how this will help those with multiple remotes (including me ;-). Thanks for moving this topic forward.
