So let me see if I understand you correctly.

On Wed, Jun 11, 2014 at 12:15:39PM +0200, Charles Brossollet wrote:
> Hi,
> I'm banging my head on this problem: I have a central repo cloned by SSH, and 
> a fork on the same server. The central remote is origin, and the fork is 
> chbrosso-wip.
> $ git remote -v | grep origin
> origin  chbrosso@lltech:/git/lightct.git (fetch)
> origin  chbrosso@lltech:/git/lightct.git (push)
> $ git remote -v | grep chbrosso-wip
> chbrosso-wip    chbrosso@lltech:~/prog/git/lightct.git (fetch)
> chbrosso-wip    chbrosso@lltech:~/prog/git/lightct.git (push)
> On a local working copy, fetched my fork and checked out a remote branch out 
> of it. Its remote-tracking branch is on the fork.
> $ git branch -vv | grep \*
> * actor                         d98ec24 [chbrosso-wip/actor] (commit msg)
> Now, submodules for this repo have relative URLs. And this is where the 
> problem begins, because the submodule isn't forked, but resides only in 
> origin.

Fork is not a git thing. It's not a git command and it's not supported
by git. You can of course easily do a "fork" of a git project, but git
will be unaware of it beeing a fork.

What you're saying is that you've one repository:

lightct.git and one other repository which is a submodule to lightct.git
at motors.git. Then you've made a copy of lightct.git to an other place
for example: /some/other/path/lightct.git and the naturally the
submodule path that's relative will point to /some/other/path/motors.git
that doesn't exists, since you haven't copied motors.git

> But this shouldn't cause any problem, right? The docs says that if relative 
> URL are used, they resolve using the origin URL. First issue, it's not the 
> case:

Orgin refers to the repository you cloned from. That is if you did
git clone lightct.git my_working_copy

the origin for my_working_copy would be lightct.git. However if you did
git clone /some/other/path/lightct.git my_working_copy

the origin for my_working_copy would be /some/other/path/lightct.git

So to me it seems to be correct.

> $ cat .gitmodules
> [submodule "motors"]
>         path = motors
>         url = ../motors.git
>         branch = master
> $ git submodule init motors
> Submodule 'motors' (chbrosso@lltech:~/prog/git/motors.git) registered for 
> path 'motors'
> Here the submodule is registered on my fork, which doesn't exist, and it's 
> wrong with what the documentation says.
> Fine, I'll edit the .git/config entry to make it point to origin:
> $ git config submodule.motors.url chbrosso@lltech:/git/motors.git
> $ git config submodule.motors.url
> chbrosso@lltech:/git/motors.git
> $ ssh chbrosso@lltech "if  [ -d /git/motors.git ]; then echo 'ok'; fi"
> Password:
> ok
> So the submodule's url is changed, and points to a correct path, let's update 
> so that I can work
> $ git submodule update motors
> Password:
> fatal: '~/prog/git/motors.git' does not appear to be a git repository
> fatal: Could not read from remote repository.
> Please make sure you have the correct access rights and the repository exists.
> Unable to fetch in submodule path 'motors'
> That's right, it is still the old url, and I can't have my submodule!

Here you change the path to the submodule at
/some/other/path/lightct.git and then it isn't changed in my_working_copy. How 
could it? They don't communicate if you don't tell them to.

> Can someone explain what's going on? And how can I get my submodule in the 
> working copy?

Either created a copy of the submodule just as you did with lightct.git
or use non-relative paths.

Med vänlig hälsning
Fredrik Gustafsson

tel: 0733-608274
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to