Nguyen Thai Ngoc Duy wrote: > On Thu, Oct 21, 2010 at 2:07 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> Â- otherwise, if original cwd was under repository, [...] >> Â GIT_WORK_TREE defaults to unset. > > What do you mean by "under repository"? If the repo is /tmp/git/.git, > then cwd is at /tmp/git/.git? I meant if the original cwd lies within the repository. Example: repo /tmp/git/.git starting cwd /tmp/git/.git/objects/pack >> D. User-supplied relative paths. >> >> Â- path in .git file is relative to containing directory >> Â- path in GIT_DIR is relative to original cwd >> Â- paths in GIT_WORK_TREE and core.worktree are relative to >> Â $GIT_DIR > > I think $GIT_WORK_TREE is relative to original cwd. git.txt is confusing, then. Actually it has some other insights: --work-tree=<path> Set the path to the working tree. The value will not be used in combination with repositories found automatically in a .git directory (i.e. $GIT_DIR is not set). So GIT_WORK_TREE should be discarded or warned about when GIT_DIR is not set. (?) This can also be controlled by setting the GIT_WORK_TREE environment variable and the core.worktree configuration variable. It can be an absolute path or relative path to the directory specified by --git-dir or GIT_DIR. This is where I got the impression about relative paths. Note: If --git-dir or GIT_DIR are specified but none of --work-tree, GIT_WORK_TREE and core.worktree is specified, the current working directory is regarded as the top directory of your working tree. Nice to see this case is documented. > Yes, core.worktree > should be relative to $GIT_DIR. 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? > Yes. Thanks for checking. Jonathan -- 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