On Thu, Dec 3, 2015 at 9:53 PM, Max Kirillov [off-list ref] wrote:

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

quoted

On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov [off-list ref] wrote:

quoted

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.

quoted

quoted

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 [off-list ref] 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