On Thu, Sep 27 2018, Duy Nguyen wrote:
> On Wed, Sep 26, 2018 at 8:25 PM Ævar Arnfjörð Bjarmason
> <avarab@xxxxxxxxx> 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.
I see I'm misremembering most of the details here. I thought that if I put:
[remote "whatever]
url = ...
Into my ~/.gitconfig that it wouldn't work, but it does, e.g. here in my
~/g/git:
$ grep -A1 whatever .git/config
$
$ grep -A1 whatever ~/.gitconfig
[remote "whatever"]
url = git@xxxxxxxxxx:test/git.git
But there's still some special casing for .git/config going on,
e.g. here:
$ git config remote.origin.url
git@xxxxxxxxxx:git/git.git
$ git config remote.whatever.url
git@xxxxxxxxxx:test/git.git
$ git remote get-url origin
git@xxxxxxxxxx:git/git.git
$ git remote get-url whatever
fatal: No such remote 'whatever'
And:
$ git remote set-url whatever git@xxxxxxxxxx:test2/git.git
fatal: No such remote 'whatever'
So there is some special casing of .git/config somewhere. I looked into
this ages ago, and don't remember where that's done.
I was wondering if these patches introduced any unwanted edge cases in
this regard, e.g. if you're using the per-worktree config, and you have
remotes in .git/config, does "git remote get/set-url" do the right
thing?
Then if we have remotes in .git/config, should we add new remotes to
.git/config or the per-worktree file? I'd lean towards .git/config,
since remotes are orthagonal to worktrees, and closely tied with refs
which are shared no matter what this extension says, but maybe there's a
good argument for doing it the other way around.
>> > 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.
