On Thu, 17 July 2008, Kevin Ballard wrote: > On Jul 17, 2008, at 1:04 PM, Jakub Narebski wrote: > >> Git submodules are roughly equivalent to svn:externals with peg >> revisions; I mean here that they refer not to some branch in some >> external repository, but to specific revision. This is the only sane >> design, as it assures that when checking out some historical revision, >> the state that is checked out will be the same for everybody. >> >> Please take into account however that submodules are quite new >> feature, and while underlying engine is solid, interface (UI) needs >> some polishing (and use cases). > > There is one facet of submodules that annoys me, because it prevents > me from using them as a replacement for svn:externals. Namely, the > submodule refers to a specific repository, but not a path within that > repository. I work with svn repos that use svn:externals to peg > revisions (as is appropriate) but they all refer to various paths > within the other repositories, and the only way I can deal with that > is to throw symlinks everywhere. I don't quite understand. At the lowest, "gitlink" level submodule entry is just having _commit_ object in place of directory. And of course this commit object refers to top tree (top directory) in a subproject. If you have subproject B with the following file structure B/foo B/bar/baz and you have (super)project A, which contains B as subproject at path sub-b, and has some files itself, the directory sytucture would look like this: A/quux A/sub-b/foo A/sub-b/bar/baz What you want, I guess, is some a bit weird for me mixture of submodule and partial (subtree) checkout... and the latter is not implemented yet (I say "yet" because there was some preliminary implementation of subtree checkout on git mailing list). -- Jakub Narebski Poland -- 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
