Re: [PATCH v2] config.c: split some variables to $GIT_DIR/config.worktree

[Max Kirillov <max@max630.net>]

On Sun, Mar 29, 2015 at 08:25:33AM +0700, Duy Nguyen wrote:
> I'm not sure if "it" means $GIT_DIR/config.worktree or
> $GIT_DIR/info/config.worktree. At this point $GIT_COMMON_DIR is not
> involved (i.e. you can still spit config even in a normal repo).
> .../info/config.worktree may be shared, I guess.

Yes, I meant info/config.worktree

> The "older versions of git (and other git implementations)" raises an
> issue with this patch. Older impl just ignore config.worktree. I think
> I need to bump core.repositoryformatversion up to avoid that.

As a user I would like to still use some older tools, so I
cannot say I like it.

And, I guess bumping repository verion is something the
whole git ecosystem has not experienced yet. So it should be
much more work and much more time, I cannot even imagine how
much. I would still search for option without bumping
version.

>> Also, probably the per-worktree variables should be searched
>> for in both common config and per-worktree config, and the
>> main repository should not have config.worktree, to be able
>> to work with implementations which are not aware of the
>> whole multiple worktrees feature. And in worktrees, if the
>> variable is not defined in config.wortree, the default
>> vaalue should come from common config. This though has
>> downside that worktree cannot use the more global vlue for
>> variable implicitly.
> 
> The main worktree may or may not use per-worktree config (it's
> technically possible): if we enforce config.worktree on the main
> worktree, we don't have to worry about the same variable defined in
> both common and per-worktree config. Enforcing may require more work:
> imagine the worktree list is updated, some in the common config may
> become per-worktree and need to be moved to config.worktree.. If we
> allow per-worktree vars in the common config, other worktrees should
> ignore them in common config.

Yes, probably always ignoring is good idea. They could be
initialized from the common config at worktree creation.

PS: I wrote that nearly all variables could be per worktree.
For maintainability probably a better idea would be to start
with as few as possible and extend their default list as
it's clear nothing will break.

-- 
Max