Thanks for taking time to understand, let me make it more clear
Le 12 juin 2014 à 17:25, Fredrik Gustafsson <iv...@iveqy.com> a écrit :
> So let me see if I understand you correctly.
> On Wed, Jun 11, 2014 at 12:15:39PM +0200, Charles Brossollet wrote:
>> 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
>> $ 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
> 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.
OK, you get it, what I mean by fork here is an independent copy of a
repository, at another remote place.
> 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
That's right. Origin is the repository that were original cloned to the working
copy, and I have a copy of it, that is in /some/other/path, without motors.git
having been copied.
I haven't copied motors.git because I won't modify it, so I still want to refer
>> 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
> 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.
No, in the working copy, origin's location isn't changed, it is still the
repository I originally (!) cloned from. I added the other remote afterward,
and named it chbrosso-wip, not origin. Then, the working copy has two remotes,
origin and chbrosso-wip. So if we follow the docs the URL for the submodule
shouldn't be set to chbrosso-wip's URL, but this is what is happening.
>> 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.
No, you missed my point, let me explain it a more synthesized way:
There are 3 repos main, fork, and sub, having the following URLs:
sub is a submodule of main, and referred with a relative URL in .gitmodules.
In a working copy, cloned from /central/main, thus referred by git as origin,
and added /user/main as another remote repository. Fetched from it.
Initially the submodule isn't cloned in the working copy.
The two problems I'm pointing are:
1. After checkout of a branch that tracks /user/main repo, call git init
submodule motors. Git registers it in .git/config with URL /user/sub, while it
should be /central/sub according to documentation because origin's URL is at
2. For an obscure reason, changing the url in .git/config to /central/sub and
call git submodule update still make git want to clone from /user/sub, and
fails. There seems to be no way to tell git the right URL for this submodule,
while it should be possible according to the submodule documentation.
>> 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: iv...@iveqy.com
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html