On Sat, Feb 14, 2009 at 06:17, Eric Kidd <git@xxxxxxxxxxxxxxx> wrote: > On Fri, Feb 13, 2009 at 11:37 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Eric Kidd <git@xxxxxxxxxxxxxxx> writes: >>> ... >>> If the submodule has moved around the source tree, specify one or more >>> values for alternate_dir. To specify the URL of the newly created >>> repository (for use in .gitmodules), use the --url parameter. >> >> Unfortunately, I do not think we have designed fully (nor implemented at >> all) behaviour to check out different points of history that has the same >> submodule moved around in the superproject tree. >> >> There were several unconcluded discussions done in the past (and I admit I >> participated in a few of them), but it may be hard to use the resulting >> repository out of this tool. > > Thank you for looking at this proposal! > > I think that the resulting repository is usable (though it could > certainly be better). In particular, the following commands will > always give you a working checkout: > > git checkout any-version > git submodule update --init > > The unit tests for git-submodule-split.sh actually walk through the > entire history and run 'git submodule update --init' at each revision. > This works correctly because git-submodule-split creates the necessary > .gitmodules entries for each revision, and includes the > submodule.*.url value that you specify. > > Unfortunately, this means that whenever the submodule moves to a new > location in the tree, 'git submodule --init' will actually have to > clone it again. That's not a perfect situation, but it will work for > reasonably small submodules. <hand-waving> 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... </hand-waving> -- 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