On Fri, Jul 17, 2015 at 7:32 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: >> In the new world order with GIT_DIR and GIT_COMMON_DIR, does >> "$GIT_DIR" always have to be the same as "$GIT_WORK_TREE/.git"? Do >> we need some sanity check if that is the case? Perhaps: if you have >> $GIT_DIR set to $somewhere/.git/worktrees/$name, then >> >> - $GIT_COMMON_DIR must match $somewhere/.git, >> >> - $somewhere/.git/worktrees/$name/commondir must point at >> $GIT_COMMON_DIR, >> >> - $GIT_WORK_TREE/.git must match $GIT_DIR >> >> or something like that? > > Duy is probably better suited to answer this, as he would likely have > taken these issues into consideration when implementing the feature. > (I've been poking through documentation and code for quite a while > trying to answer this email but don't yet have a sufficient grasp to > do it justice. I'm not even sure where such a sanity check would be > placed.) The thing is, we just don't know where the worktree is. All we know is somewhere there is a .git file sharing this repository. People can create a linked worktree, then move the actual linked worktree away, set GIT_DIR/GIT_WORK_TREE to reflect that, and everything must still work. So, we could say "foo is already checked out at the worktree that is linked to /some/path/.git" to be technically correct. But that's not so friendly? We could cache the $GIT_WORK_TREE, when the user accesses the linked checkout, somewhere in .git/worktrees/foo and show it instead of /some/path/.git. But that's not always accurate. -- 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