On Fri, May 25, 2018 at 8:38 PM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > On Fri, May 25 2018, Duy Nguyen wrote: > >> On Fri, May 25, 2018 at 10:12 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>>> +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? >> >> I still plan to revisit per-worktree config support [1] at some point >> and finish it off. Or is it decided that we don't need a generic >> mechanism and will add a new level like this for each config var that >> is per-worktree? If defaultRemote sets a precedence, then it'll be the >> way to go from now on or we'll have another mess when some config does >> "foo.$worktree.bar" while others use per-worktree config files. > > What do you think about including worktree in this at this time? I'm not > very familiar with it and just included it because I worked my way > backwards from the DWIM function, but I could exclude it if you think > it's too much trouble, i.e. if you'd like to hold out for some facility > like the per-worktree config Junio mentioned. I think Junio was talking about the future. What is currently in the patch, both code and document, is fine. But if you're going to implement core.$worktree.defaultRemote at this time, maybe wait a bit. I could try to resurrect the per-worktree config topic in a month or so and if it does not work out, then everybody will add new config vars if they want per-worktree support. -- Duy