Adding the list back on. On Sun, Oct 9, 2016 at 1:56 PM, Dennis Kaarsemaker <den...@kaarsemaker.net> wrote: > On Sun, 2016-10-09 at 21:15 +0200, ven...@gmail.com wrote: >> Sure, http://pastebin.com/bUFBDj0Q > > So you actually cloned from a path ending in epihany/, not epiphany. > Turns out the trainling slash matters when using relative urls for > submodules: > > $ cat test.sh > url=http://remote.example/repo > > for url in $url "$url/"; do > echo "Remote: $url" > rm -rf main > git init -q main > ( > cd main > git remote add origin $url > git init -q sub > git -C sub commit --allow-empty -mtest > printf '[submodule "sub"]\n\tpath = sub\n\t\turl = ../sub\n' > > .gitmodules > git add sub .gitmodules > git commit -mtest > git submodule init > ) >/dev/null > done > > $ sh test.sh > Remote: http://remote.example/repo > Submodule 'sub' (http://remote.example/sub) registered for path 'sub' > Remote: http://remote.example/repo/ > Submodule 'sub' (http://remote.example/repo/sub) registered for path 'sub' > > I don't know whether this is a bug or a feature. I find using relative > paths for submodules a pretty dodgy idea anyway and would fix up the > .gitmodules file.
I disagree here, IMHO relative path/urls are better than absolute URLs as it allows to hand over a project to a different organisation that wants to have its own fork including submodule changes just easily (no need to muck around the submodule config, "it just works" ;) > > Stefan, is it possible that this is a regression in the C rewrite? Totally possible! Thanks for the regression test, I'll dive into the code tomorrow. Thanks, Stefan > > D. >
