On Sun, 9 Dec 2007, Wink Saville wrote: > Daniel Barkalow wrote: > > On Sun, 9 Dec 2007, Wink Saville wrote: > > > > I think that submodules do what you want. And they may not be ready for > > neophytes to just use, but they're ready for neophytes to try using and tell > > us where things get confused. > > > <snip> > > -Daniel > I would like to try submodules and started to read the man > > > I'll try submodules and I'll start by reading the man page, > I got to "add" and did the following: > > wink@ic2d1:$ mkdir x > wink@ic2d1:$ cd x > wink@ic2d1:$ git init > Initialized empty Git repository in .git/ > wink@ic2d1:$ git-submodule add ../android/StateMachine > remote (origin) does not have a url in .git/config > you must specify a repository to clone. > Clone of '' into submodule path 'StateMachine' failed It looks like git-submodule does something really wrong for URLs that start with ./ or ../. (By "wrong", I mean that it's different from the handling of the same URL anywhere else.) I think there's a general problem (beyond submodule support) that git doesn't do a good job with intermediate repositories: if you clone a repository, and then clone the clone, the second clone sees the local-to-the-first aspects and largely ignores the actual origin's properties. On the other hand, you probably don't really want the canonical URL for the submodule to be a local relative path. If what you have are local clones of public repositories, you want to use the public remote repositories' URLs there. If you really want it to be a clone of the local repository, you can use an absolute path and weird things won't happen. I think it should be possible to store the submodule data in the 'x' repository as well; have some branches which are the three different projects, and then pull them out of '.', but this doesn't seem to be working for me, either. > The documentation for "submodule add" says: > > /git-submodule/ [--quiet] [-b branch] add <repository> [<path>] > Add the given repository as a submodule at the given path to the changeset to > be committed next. > > From the above, <path> is ambiguous to me, is it referring to the source or > destination. I continue reading and in the options section we find: > > <path> > > Path to submodule(s). When specified this will restrict the command > to only operate on the submodules found at the specified paths. > > So it seems <path> is the for the source, but some how it can specify multiple > paths. This is actually the destination. The projects that are under discussion are only submodules in the context of the destination. For "git submodule add" it's the path in the superproject where the submodule will appear. -Daniel *This .sig left intentionally blank* - 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
