On Mon, Dec 27, 2021 at 2:15 AM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > On Wed, Dec 22, 2021 at 5:54 PM Elijah Newren <newren@xxxxxxxxx> wrote: > > I think that "git > > worktree add" should check if either core.bare is false or > > core.worktree is set, and if so then set extensions.worktreeConfig and > > migrate the relevant config. > > Similar to my response to Sean in [1] and to Stolee in [2], while this > may help the situation for worktrees created _after_ > `extensions.worktreeConfig` is enabled, it does _not_ help existing > worktrees at all. For this reason, in my opinion, `git worktree add` > is simply not the correct place to be addressing this problem, and > it's why I suggested a separate command for enabling the feature and > doing all the necessary bookkeeping. It's also why I suggested[2] that > in the long run, we may want per-worktree config to be the default > (and only) behavior rather than the current (legacy) behavior of all > config being shared between worktrees. Thinking upon it further, I take back what I said about it not helping existing worktrees. Your proposal is _almost_ the same as my suggestion of eventually making per-worktree config the default. The difference is that you're only making it the default if `core.bare=true` or `core.worktree` is set. But do we need that distinction? If people are comfortable with that, then are they comfortable with simply flipping the switch and making per-worktree config the default today regardless of `core.bare` and `core.worktree`? I'm not sure that I'm comfortable with it due to the potential of breaking older versions of git which don't understand `extensions.worktreeConfig`, as well as breaking third-party tools, but maybe other people feel differently?
