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 e-post: iveqy@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html