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

[Duy Nguyen]

On Thu, Dec 3, 2015 at 9:53 PM, Max Kirillov  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  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  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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Duy Nguyen]

On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov  wrote:
> On Wed, Dec 02, 2015 at 08:13:41PM +0100, Nguyễn Thái Ngọc Duy wrote:
>> Let's restart this. From the last discussion [1], we need to make
>> core.worktree per-worktree for submodules to work. We also need
>> core.sparseCheckout per-worktree.
>
> Thank you. It would be nice to have it, so that features
> like submodules work fully.
>
> Now there are extensions support, would it make sense to
> mark repositories which use per-worktree config with an
> extension? It could clearly separate 2.5-style
> multi-worktree repositories (which might exist already
> around) from the new format. The extension could be set by
> 'worktree add' while creating first worktree, for example.

Hmm.. I didn't think of this. If we add this as a repo extension, then
we could use git/config for shared vars only, main worktree specific
vars can stay in .git/config.worktree while linked worktree's in
.git/worktrees/*/config.worktree. Neat.

>> This series adds a pattern list, with .gitignore syntax mostly, that
>> split config var set into two sets, the per-worktree set will be
>> stored in .git/worktrees/*/config.worktree instead. The pattern list
>> consists of default patterns, built in git binary, and user ones in
>> .git/info/config.worktree.
>
> 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

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

If a variable _must_ be per-worktree or something will break, then it
should belong to the builtin list (so the user is less likely to mess
with it). If it may or may not be per-worktree, depending on one's
preference, then we can keep this in info/config.worktree. I made the
builtin list for that reason (user not breaking stuff accidentally)
and another one, which is upgrade issue. 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.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

Duy Nguyen  writes:

> If a variable _must_ be per-worktree or something will break, then it
> should belong to the builtin list (so the user is less likely to mess
> with it). If it may or may not be per-worktree, depending on one's
> preference, then we can keep this in info/config.worktree. I made the
> builtin list for that reason (user not breaking stuff accidentally)
> and another one, which is upgrade issue. 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.

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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Max Kirillov]

On Thu, Dec 03, 2015 at 09:07:07AM +0100, Duy Nguyen wrote:
> On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov  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.

>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Max Kirillov]

On Thu, Dec 03, 2015 at 11:52:43AM -0800, Junio C Hamano wrote:
> I actually prefer *not* to have any configurability
> to avoid confusion between users.

This could be an approach. But because of upgrade issues
which I described in the other response it looks like this
decision is not easy to change in a later version. So the
list should be decided here and now for each existing
variable, and later for any new one, and preferable never
changed after that.

-- 
Max
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Max Kirillov]

On Wed, Dec 02, 2015 at 08:13:41PM +0100, Nguyễn Thái Ngọc Duy wrote:
> Let's restart this. From the last discussion [1], we need to make
> core.worktree per-worktree for submodules to work. We also need
> core.sparseCheckout per-worktree.

Thank you. It would be nice to have it, so that features
like submodules work fully.

Now there are extensions support, would it make sense to
mark repositories which use per-worktree config with an
extension? It could clearly separate 2.5-style
multi-worktree repositories (which might exist already
around) from the new format. The extension could be set by
'worktree add' while creating first worktree, for example.

> This series adds a pattern list, with .gitignore syntax mostly, that
> split config var set into two sets, the per-worktree set will be
> stored in .git/worktrees/*/config.worktree instead. The pattern list
> consists of default patterns, built in git binary, and user ones in
> .git/info/config.worktree.

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

-- 
Max
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html