Problem with submodules

Problem with submodules

[venv21]

Hi, I want to report a regression.

After cloning for example https://git.gnome.org/browse/epiphany with
git 2.10 and running ./autogen.sh I get the following errors:
http://pastebin.com/93AunRhu

The developer told me that it is probably not an issue caused by
epiphany and I should try an older git version. I installed 2.7.2 and
it works perfectly. So I think theres a bug in git 2.10.

Thanks and regards

Re: Problem with submodules

[Dennis Kaarsemaker]

On Sun, 2016-10-09 at 16:41 +0200, venv21@gmail.com wrote:
> Hi, I want to report a regression.
> 
> After cloning for example https://git.gnome.org/browse/epiphany with
> git 2.10 and running ./autogen.sh I get the following errors:
> http://pastebin.com/93AunRhu
> 
> The developer told me that it is probably not an issue caused by
> epiphany and I should try an older git version. I installed 2.7.2 and
> it works perfectly. So I think theres a bug in git 2.10.

I can't reproduce the problem with git 2.10.1

Can you share the .git/config file in your clone of epiphany please.

D.

Re: Problem with submodules

[venv21]

Sure, http://pastebin.com/bUFBDj0Q

Re: Problem with submodules

[venv21]

hm okay, it works with 2.10.0, when I remove the word 'epiphany' from
the urls in line 13 and 15

2016-10-09 21:15 GMT+02:00 venv21@gmail.com <venv21@gmail.com>:
> Sure, http://pastebin.com/bUFBDj0Q

Re: Problem with submodules

[Stefan Beller]

Adding the list back on.

On Sun, Oct 9, 2016 at 1:56 PM, Dennis Kaarsemaker
<dennis@kaarsemaker.net> wrote:
> On Sun, 2016-10-09 at 21:15 +0200, venv21@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.
>

Problem with submodules

[Andrew Neil]

I am having trouble with submodules on one of my machines. When I run
`git submodule init`, then `git submodule update`, it looks as though
everything is going fine, then it crashes out with an error:
"pathspec '665a3c' did not match any file known to git.".
(The full output is pasted below).

According to this article: http://book.git-scm.com/5_submodules.html
under the heading "Pitfalls with submodules", this error is expected
to occur if you don't publish changes to a submodule. This doesn't
seem to be the problem in my case. I have tried installing the same
git repository on 2 other machines, and the submodule init/update
commands worked fine on both of them. So it looks as though there is
something on one of my machines that is interfering with this process.

I discovered that if I run the `git submodule update` command as sudo,
the problem goes away. However, this has the side-effect that the
submodule directories are created with root as the owner.

Can anyone help with this problem?

Much appreciated,
Drew


Here is the full output of the init/update commands, with my faulty
machine:

$ git submodule init
Submodule 'vendor/plugins/dataset' (git://github.com/jgarber/ 
dataset.git) registered for path 'vendor/plugins/dataset'
Submodule 'vendor/plugins/simply_versioned' (git://github.com/mmower/ 
simply_versioned.git) registered for path 'vendor/plugins/ 
simply_versioned'
$ git submodule update
Initialized empty Git repository in /Users/drew/web/extensions/ 
chronicle/vendor/plugins/dataset/.git/
remote: Counting objects: 899, done.
remote: Compressing objects: 100% (692/692), done.
remote: Total 899 (delta 539), reused 250 (delta 158)
Receiving objects: 100% (899/899), 141.93 KiB | 42 KiB/s, done.
Resolving deltas: 100% (539/539), done.
error: pathspec '665a3c03f6a65a586839b8de437c60f98177dd78' did not  
match any file(s) known to git.
Unable to checkout '665a3c03f6a65a586839b8de437c60f98177dd78' in  
submodule path 'vendor/plugins/dataset'

Re: Problem with submodules

[Andrew Neil]

I found a solution to this here:

	http://www.websideattractions.com/2008/10/21/no-color-for-git/

Turns out that the following line in my .profile was messing things up:

	GREP_OPTIONS="--color=always"; export GREP_OPTIONS

I changed --color=always to auto, and everything works fine now.

Cheers,
Drew


On 29 May 2009, at 12:44, Andrew Neil wrote:

> I am having trouble with submodules on one of my machines. When I run
> `git submodule init`, then `git submodule update`, it looks as though
> everything is going fine, then it crashes out with an error:
> "pathspec '665a3c' did not match any file known to git.".
> (The full output is pasted below).
>
> According to this article: http://book.git-scm.com/5_submodules.html
> under the heading "Pitfalls with submodules", this error is expected
> to occur if you don't publish changes to a submodule. This doesn't
> seem to be the problem in my case. I have tried installing the same
> git repository on 2 other machines, and the submodule init/update
> commands worked fine on both of them. So it looks as though there is
> something on one of my machines that is interfering with this process.
>
> I discovered that if I run the `git submodule update` command as sudo,
> the problem goes away. However, this has the side-effect that the
> submodule directories are created with root as the owner.
>
> Can anyone help with this problem?
>
> Much appreciated,
> Drew
>
>
> Here is the full output of the init/update commands, with my faulty
> machine:
>
> $ git submodule init
> Submodule 'vendor/plugins/dataset' (git://github.com/jgarber/ 
> dataset.git) registered for path 'vendor/plugins/dataset'
> Submodule 'vendor/plugins/simply_versioned' (git://github.com/mmower/ 
> simply_versioned.git) registered for path 'vendor/plugins/ 
> simply_versioned'
> $ git submodule update
> Initialized empty Git repository in /Users/drew/web/extensions/ 
> chronicle/vendor/plugins/dataset/.git/
> remote: Counting objects: 899, done.
> remote: Compressing objects: 100% (692/692), done.
> remote: Total 899 (delta 539), reused 250 (delta 158)
> Receiving objects: 100% (899/899), 141.93 KiB | 42 KiB/s, done.
> Resolving deltas: 100% (539/539), done.
> error: pathspec '665a3c03f6a65a586839b8de437c60f98177dd78' did not  
> match any file(s) known to git.
> Unable to checkout '665a3c03f6a65a586839b8de437c60f98177dd78' in  
> submodule path 'vendor/plugins/dataset'
>