From: Max Kirillov Date: Mon, 30 Mar 2015 21:26:42 GMT Subject: Re: [PATCH v2] config.c: split some variables to $GIT_DIR/config.worktree Message-ID: <20150330212642.GA28003@wheezy.local> In-Reply-To: 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