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