Am 08.01.2013 15:32, schrieb W. Trevor King: > On Mon, Jan 07, 2013 at 07:59:53AM +0100, Jens Lehmann wrote: >> Am 07.01.2013 02:39, schrieb Jonathan Nieder: >>> (just cc-ing Jens and Peter, who might be interested) >> >> I´m currently working on teaching mv to move submodules and intend >> to send those patches to the list after finishing submodule deinit. >> Please see >> https://github.com/jlehmann/git-submod-enhancements/commits/mv-submodules >> for the current state of this series. > > Thinking about this a bit more, I'm not clear on how out-of-tree > updates (i.e. worktree in .git/modules/*/config) propogated during > branch checkouts (merges, rebases, etc.). I just got a broken rebase > trying to move a trivial patch back before the submodule move, and Git > was confused about what had happened to the submodules. Here's a > simple script that illustrates the problem: > > #!/bin/sh > rm -rf a b c > mkdir a > (cd a > git init > echo a > README > git add README > git commit -am 'a' > ) > git clone a b > (cd b > git submodule add ../a submod-1 > git commit -am 'add submodule at submod-1' > ) > git clone b c > (cd c > git submodule update --init > ) > (cd b > git-submodule-mv.sh submod-1 submod-2 > git commit -am 'move submodule from submod-1 to submod-2' > ) > (cd c > git pull > ls -d .git/modules/* > cat .git/modules/submod-1/config > ls -a submod* > ) > > The end result is that `c` gets the `.gitmodules` path updates and new > gitlinked directory from the submodule move in `b` (using my > git-submodule-mv.sh posted earlier in this thread), but `submod-1` is > left lying around (because Git doesn't know that it can remove > submod-1/.git and submod-1/README). That's just what current git does with removed submodules (but my recursive submodule update series will handle that just fine). > The Git directory for the > submodule stays in .git/modules/submod-1/ (good), but the worktree in > .git/modules/submod-1/config still points to ../../../submod-1 (bad). You'll not only have to update the gitfile but also the core.worktree setting in the repo. Sorry I missed that when you posted your script. > This means that submodule moves are possible, but anyone trying to > share them between several repositories (or trying to rebase across > the move within their own repository) is in for a world of suffering > ;). I'm not sure how this should be addressed, but I didn't see > anything handling it in Jens' new series. If you adjust core.worktree properly you'll just have the old submodule work tree lying around (just like you do after you rm'd it) and everything apart from that should just work. As I mentioned that will be fixed by recursive submodule checkout. I'll see if I can polish my preliminary branch so that interested people can play around with it if anyone is interested. -- 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