Hi, On Sat, 14 Feb 2009, Lars Hjemli wrote: > 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> How should that help with the _working directory_ of the submodule? After all, _that_ is the part we are having with, as the untracked files in that directory _are_ part of the submodule. The real kicker is that when we want to "git submodule checkout" the (moved) submodule, we no longer know where it was found last time (and where it still is). We need a sane semantic for that (and I think it involves the addition of submodule.<name>.path to the superproject's config, something we do not do yet). Ciao, Dscho -- 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
