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

[Duy Nguyen <pclouds@gmail.com>]

On Thu, Dec 3, 2015 at 9:53 PM, Max Kirillov <max@max630.net> wrote:
> On Thu, Dec 03, 2015 at 09:07:07AM +0100, Duy Nguyen wrote:
>> 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.

I wouldn't. I mean, I have more than a dozen of git repos lying
around, some I don't even remember where. Should I check git release
notes at every upgrade then fix up _all_ of my repos? That's something
I rather not do.

>>> 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?

Behavior differences between git versions have been alway will always
be the problem. Yes providing some forward compatibility (by storing
some logic outside the binary in this case) helps, but I don't think
it eliminates it. If incompatibilities may lead to a big problem, then
we can always make the new behavior an "repo extension" to stop older
binaries from accessing the touched repos.

Most of the time there's only one git version being used. So it should
not be a big problem. But yes, if a repo is shared over network, then
multiple git versions accessing the same repo can happen.

On Thu, Dec 3, 2015 at 8:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I agree with your reasoning to have built-in set of files that are
> per-worktree. I actually prefer *not* to have any configurability
> to avoid confusion between users.

There are a set of variables where whether they are shared or
per-worktree is pretty much preference. For example, core.ignoreCase.
What if I put one worktree on that case-insensitive file system? This
gives the user some flexibility in managing those variables. _But_
they can also manage another way with include.path (or a new variant
that is worktree-aware), with a bit of work.

So killing info/core.worktree is not a bad idea. Even better, we can
avoid pulling exclude machinery in. But yeah, need to sort out the
upgrade issue Max mentioned first.
-- 
Duy