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

Johannes Schindelin wrote:

Hi,

On Mon, 11 Feb 2008, Mark Levedahl wrote:

  

quoted

Johannes Schindelin wrote:

    

quoted

quoted

@@ -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