On Wed, Sep 26, 2018 at 8:25 PM Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Sun, Sep 23 2018, Nguyễn Thái Ngọc Duy wrote: > > > +extensions.worktreeConfig:: > > + If set, by default "git config" reads from both "config" and > > + "config.worktree" file in that order. > > How does this interact with config that's now only used if it's in > .git/config? E.g. you can't set remote.<remote>.<url> in ~/.gitconfig, > will that be inherited across the two of these?
Er... we can't? If I remember correctly we don't have any enforcement on where what config vars must or must not go. The only exception is core.bare and core.worktree which is only read from $GIT_DIR/config because of the way they are involved in .git directory discovery. If I put remote "foo" in ~/.gitconfig, "git remote" happily reports remote "foo" to me. To sum up, we always inherit config from higher levels, with /etc/gitconfig being the highest and $GIT_DIR/config the lowest. It's up to the user to share config between repos responsibly. This patch only adds one more level, $GIT_DIR/config.worktree which is now the lowest level. > > In multiple working > > + directory mode, "config" file is shared while > > + "config.worktree" is per-working directory. > > "But then how will it work with more than one?" I found myself thinking > before reading some more and remembering .git/worktree. Shouldn't we > consistently say: > > [...]"config" and "worktrees/<worktree name>/config"[...] > > Or something like that? Point taken. Maybe I'm trying to hide implementation details too much. -- Duy
