On Fri, May 25 2018, Duy Nguyen wrote: > On Fri, May 25, 2018 at 10:12 AM, Junio C Hamano <gits...@pobox.com> 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.
