Dear gitsters, dear Lars, while testing some workflows with submodules, we ran into the problem that adding a submodule seems to require a remote "origin" to be defined, even though that is not really necessary: ### subproj setup: % GIT_DIR=subproj.git git --bare init Initialized empty Git repository in /tmp/madduck/cdt.ciwkf2/subproj.git/ % mkdir subproj && cd subproj % git init && git remote add origin ../subproj.git Initialized empty Git repository in /tmp/madduck/cdt.ciwkf2/subproj/.git/ % touch a && git add a && git commit -minitial && git push origin master [master (root-commit) 7f6f6e9] initial 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 a Counting objects: 3, done. Writing objects: 100% (3/3), 201 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To ../subproj.git * [new branch] master -> master ### test project setup: % mkdir ../proj && cd ../proj % git init Initialized empty Git repository in /tmp/madduck/cdt.ciwkf2/proj/.git/ % touch a && git add a && git commit -minitial [master (root-commit) aa15bae] initial 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 a ### adding submodule: % git submodule add ../subproj.git remote (origin) does not have a url defined in .git/config The requirements stems from the resolve_relative_url() function in git-submodule, which assumes that a relative submodule URL is relative to the superproject's default remote URL. This might make sense for './' URLs, but not really for '../'. Plus, it breaks the normal assumption that Git accepts relative (filesystem) paths as URLs (works for git-clone etc.). Before I work out a patch for this, I would be curious to hear your thoughts. Thanks, -- martin | http://madduck.net/ | http://two.sentenc.es/ fighting for peace is like screwing for virginity. -- the irish times, washington dc spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)