On 11-07-27 03:00 PM, Phil Hord wrote: > On 06/01/2011 11:55 AM, Marc Branchaud wrote: >> On 11-05-31 06:04 PM, Phil Hord wrote: >>> On 05/31/2011 04:57 PM, Marc Branchaud wrote: >>>> - The current code rewrites the URL so that any relative path is either >>>> rejected or munged into an absolute remote URL. >>> I don't see the URL getting munged away from being relative. Can you >>> point to an example? >> I reached this conclusion because if I go into my clone of git.git and do >> >> git submodule add ../MyThing >> >> where ../MyThing is a regular git repo, I get >> >> Cloning into MyThing... >> fatal: The remote end hung up unexpectedly >> Clone of 'git://git.kernel.org/pub/scm/git/MyThing' into submodule path >> 'MyThing' failed >> >> So it seemed the relative URL became an absolute URL. >> >> Looking more closely at a working example, I can see that (as you show below) >> the URL in the super-repo's .gitmodules file retains the relative path, but >> the submodule's remote.origin.url is an absolute path. >> >> In any case, "submodule add" isn't doing what I expected: make my local >> MyThing repo a submodule of my git.git clone. > > I thought I understood this workflow better than I actually did. I > think I understand more now, and I'm somewhat disappointed. But I also > failed to pick up the ball on this old discussion. > > If you do this, I think it will work like you were hoping: > > :: ( mkdir MyThing && cd MyThing && git init ) > Initialized empty Git repository in /opc/git/MyThing/.git/ > :: git submodule add ../MyThing > Adding existing repo at 'MyThing' to the index I see how that works, but I don't find that intuitive at all. For one, ../MyThing doesn't even exist, neither locally or on the origin repo. It's really ./MyThing (with one dot). The last idea that I'd come up with for adding ./MyThing as a submodule would be to use ../MyThing. What git does in this case actually looks like a bug to me. I'd expect "git submodule add ../MyThing" to fail if there's no local ../MyThing and no remote ../MyThing. > Furthermore, the relative path only works for URLs. It does not work > for local filesystems. Well, sort of. From the current man page: "If the superproject doesn't have an origin configured the superproject is its own authoritative upstream and the current working directory is used instead." I submitted two patches to clarify the documentation on that point: http://article.gmane.org/gmane.comp.version-control.git/175163 http://article.gmane.org/gmane.comp.version-control.git/175162 They seemed to have been lost in the shuffle, though. M. -- 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