Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > So in the long run I suspect we might have to change core git anyways > to make moving submodules easy for the user (surely "git mv" and maybe > also the setup and gitfile code). Does that make more sense? If you need to change "git mv" anyway to help moving submodule checkout, then how gitfile points into .git/modules/ hierarchy of the superproject becomes an implementation detail the end users should not have to care about. What does "if we reached thru a gitfile, then the working tree is where you found that gitfile" really solve? The way you found that gitfile is by traversing the directory hierarchy upwards from a subdirectory of a working tree of a submodule, and you already know where the top of that working tree is, no? And the heuristics would not work if somebody goes into the $GIT_DIR/ that governs the submodule as going upwards from there will not hit gitfile, so we would need help from core.worktree anyway. A non-submodule setting that uses gitfile would need to worry about core.worktree, too, so I'd rather avoid loading more heuristics to gitfile handling unless there is a clear advantage for doing so, which I am not really seeing here. That is not really a "If not" below (i.e. I am not saying it is _not_ OK. I am saying I don't know what the advantage of that approach is), but ... > If not I'm fine with just setting core.worktree to a relative path in > the git-submodule.sh script (like I did for the gitfile). And I'll look > into teaching "git mv" about submodules right after that. ... teaching "git mv" may be a good move, I would think. I do think keeping core.worktree pointing at the right directory is necessary, but I do not see much point in making it a relative path, though. -- 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