[* sorry for the late reply *] On Tue, Feb 17, 2009 at 11:17, Nanako Shiraishi <nanako3@xxxxxxxxxxx> wrote: > Quoting Lars Hjemli <hjemli@xxxxxxxxx>: > >> I didn't look at the patch, but if the submodule uses a single >> module-name while moving around, the re-cloning problem would by >> solved if the submodule git-dir was stored inside the git-dir of the >> containing repository (by using the git-file mechanism). Maybe I >> should try to finally implement this... > > Is it similar to what was discussed earlier in the thread > http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621 > (I asked gmane for "submodule relocate")? Well, kind of. We ended up with a scheme similar to what Junio described in the linked mail: every submodule in a repository is given a canonical name by the .gitmodules file and this name is then linked with a url in .git/config. The .gitmodules file also states at which path(s) this submodule is located. So we can keep track of which submodules we're interested in (and what urls to use for fetching objects to those submodules) irrespective of the path used to check out the submodules. But when we're switching between branches in which a submodule is checked out at different paths, we currently loose track of both the old worktree and its gitdir. My gitfile proposal would salvage the gitdir but, as Dscho mentioned, uncommited+untracked data in the worktree would not be handled. So I currently think it's better to make `git submodule init` update .git/config with information about the current submodule path (again, as Dscho mentioned). Then, after switching branches, `git submodule <some-verb>` could notice that the current path is different from the one in .git/config and simply `mv oldpath newpath` before updating .git/config with the new path. Btw. this wouldn't work smoothly if a single submodule was checked out at multiple paths in the same revision, but I don't see why anyone would want to do something like that... -- larsh -- 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
