Re: [PATCH 1/3] git-submodule - Follow top-level remote on init/update/clone

From: Mark Levedahl <mlevedahl@gmail.com>
Date: Feb 12, 2008, 01:34 UTC
Message-ID: <47B0F78C.1050605@gmail.com>
In-Reply-To: <alpine.LSU.1.00.0802120109270.3870@racer.site>

Johannes Schindelin wrote:

Show 30 quoted lines

> Hi,
>
> On Mon, 11 Feb 2008, Mark Levedahl wrote:
>
>   
>> Johannes Schindelin wrote:
>>
>>     
>>>> @@ -107,7 +112,7 @@ module_clone()
>>>>  	test -e "$path" &&
>>>>  	die "A file already exist at path '$path'"
>>>>  -	git-clone -n "$url" "$path" ||
>>>> +	git-clone -n -o "$remote" "$url" "$path" ||
>>>>  	die "Clone of '$url' into submodule path '$path' failed"
>>>>  }
>>>>      
>>>>         
>>> If you do _that_, you will _force_ the submodule to have no "origin" 
>>> remote.  As discussed _at length_, this is not what you should do.  
>>> The only reason to use "-o <other-nick-name>" is if you plan _not_ to 
>>> use the same URL for the default remote.
>>>       
>> This *must* define the remote using the same name as flowed down from 
>> top-level, whatever that name is.
>>     
>
> At this point, I give up my review in despair,
> Dscho
>
>

The submodules must use the same remote name to refer to the same server/repo-tree as top-level, or the coordinated fetch / update driven by top-level's branch.<name>.remote cannot work. It is always origin, or always frotz, not mix and match. There are two ways to achieve this:

1) Use the name given by top-level, as I did.
2) Restrict git to only allow one remote name, *origin*, ever (or at 
least if submodules are used). Not just the default remote, *any* 
remote. This removes branch.<name>.remote as that is defined to be origin.

I infer you choose option 2? It is certainly simpler, though significantly more restrictive.

Mark