On Tue, Feb 04, 2014 at 11:20:39AM +0100, Daniel Hahler wrote:
> when using a submodule "sm", there is a relative worktree in its config:
> worktree = ../../../smworktree
> git-new-worktree (from contrib) symlinks this config the new worktree.
> From inside the new worktree, git reads the config, but resolves the
> relative worktree setting based on the symlink's location.
Hmm.. core.worktree is relative to $GIT_DIR. Whether "config" is a
symlink should have no effects.
$ ls -l .git/config
lrwxrwxrwx 1 pclouds users 11 Feb 9 15:57 .git/config -> /tmp/config
$ cat /tmp/config
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
worktree = ../../worktree
$ ls -l /tmp/worktree/
-rw-r--r-- 1 pclouds users 5 Feb 9 15:59 abc
$ ~/w/git/git ls-files -o
Maybe it's something else. Could you produce a small test case?
> A fix would be to resolve any relative worktree setting based on the
> symlink target's location (the actual config file), and not from the
> This is with git version 18.104.22.168.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html