Re: [PATCH 0/5] Split .git/config in multiple worktree setup

From: Max Kirillov <max@max630.net>
Date: Dec 3, 2015, 20:53 UTC
Message-ID: <20151203205318.GA10006@wheezy.local>
In-Reply-To: <CACsJy8AOeFEKhhmH-TCK6gWZQAJX0kbTS0-=iyCji9eXwBr9QA@mail.gmail.com>

On Thu, Dec 03, 2015 at 09:07:07AM +0100, Duy Nguyen wrote:

Show 6 quoted lines

> On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov <max@max630.net> wrote:
>> Using builtin defaults might be confusing for users -
>> editing the info/config.worktree they must keep in mind the
>> list of defaults (which they seem to don't know).
> 
> All per-worktree variables are marked so in config.txt

If I were user I would like the list to be more explicit.

Show 9 quoted lines

>> Also, if
>> anybody wants to extend the default list (like myself, for
>> submodules), should they edit the info/config.worktree in
>> provided template of extend the builtin list? What was wrong
>> with the default in template?
> 
> Suppose you introduce a new
> per-worktree variable in the new git version. If it's in the builtin
> list, we don't have to update every repo's info/config,worktree.

But how do you see it? Let's, for example, git-N consider some variable as per-repository, and user does have it their .git/config. Then git-N+1 considers it as per-worktree. How does it find the variable while opening some existing worktree? Then, if user sets the variable in some worktree using git-N+1, git-N will no longer be able to see the correct variable value. Does this mean that any change in builtin list should cause repository incompatibility?

With defaults written in the info/config.worktree file the issue do not exist at all: you can open repository created with a git version with some default list of per-worktree veriables with a version with other default list. It all would work.

If user decides to change the actual list of default per-worktree variable it is always can be done explcitly, with some provided convenience command for example.

-- 
Max