Adding the list back on.
On Sun, Oct 9, 2016 at 1:56 PM, Dennis Kaarsemaker
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.
>