On Thu, Oct 21, 2010 at 11:01 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Nguyen Thai Ngoc Duy wrote: >> On Thu, Oct 21, 2010 at 10:30 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > >>> Speaking of which, it is not clear to me that core.worktree should >>> fall under the forbidden case discussed above. ÂIf it does, what is >>> the point of making it configurable? >> >> I was not the one who introduced core.worktree, so I can't really >> tell. Maybe less keystrokes? > > Yeah, it seems you're totally right. :( Actually I have my part in this mess too: f5e025a (Documentation: always respect core.worktree if set - 2009-12-29). I probably just updated the document according to the code. It matches what Enrico expects (i.e after .git discovery, worktree defaults is "../", if core.worktree exists, follow it instead). Going back to the first commit that introduced separate worktree, 892c41b (introduce GIT_WORK_TREE to specify the work tree - 2007-06-06), core.worktree is no different than --work-tree. So what should it behave? Either revert f5e025a and update the code to disregard/warn core.worktree if GIT_DIR/--work-tree is unset, or keep the current behavior, i.e. core.worktree is different from --work-tree/GIT_WORK_TREE. The cleanup commit, e90fdc3 (Clean up work-tree handling - 2007-08-01), also gives something interesting regarding bare repo: "--work-tree=bla overrides GIT_WORK_TREE, _which overrides core.bare = true_, which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR ends in /.git, which overrides the directory in which .git/ was found.". I don't like this overriding chain, which is why I proposed to die() if core.bare is set and worktree is explicitly specified. -- Duy -- 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