Am 03.01.2012 23:17, schrieb Junio C Hamano: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > >> Not if we would implement a "if no worktree is set but we came here via >> a gitfile, then take the directory the gitfile was found in as worktree" >> heuristic. And that heuristic looks quite sane to me, as a gitfile can >> only be found in a work tree, or am I missing something obvious here? > > Like it wouldn't work without changes to the core side? I totally agree that when just talking about being able to move the superproject around that approach is more invasive than just adding a relative core.worktree setting and is just not worth the hassle. But I was also thinking about moving the submodule around inside the superproject. Until the gitfile was used that meant just mv'ing the submodule and changing the path in .gitmodules accordingly. Now you also have to adjust the core.worktree setting and maybe also the gitfile content (if you move the submodule out of the directory level it lived in before). One solution I can think of is to teach "git mv" about submodules and let it do the necessary changes to .gitmodules (which seems to be a good idea anyways), core.worktree and the gitfile. The manipulation of core.worktree could be obsoleted by not using that setting but instead implementing the heuristic I described above. And if the gitfile could be taught somehow that a path in there is relative to the superprojects root directory, then it would never have to be changed either, restoring the behavior we had before introducing the gitfile. 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 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. -- 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