Re: [PATCH] git-submodule - allow a relative path as the subproject url

Michael Smith wrote:

Hi Mark,

I have a use case where this would be very handy -- two teams geographically
separated. But in the end I think I disagree with it: it's not up to me, as the
person creating a superproject, to decide that anyone who forks or clones it
also has to clone all the submodules.

  

With or without the patch, the cloner has to execute "submodule init" 
and "submodule update" to actually check things out. Absolutely nothing 
has changed there: it still requires the same explicit actions to get 
the submodules.

This patch does not alter any existing behavior: it provides an 
additional option, and one that is very useful in a world of mirrors. My 
particular use case is for a geographically distributed work flow 
involving several mirrors, all of which are behind firewalls and/or 
connected only to a LAN. There is no single server that is available to 
everyone, hence no single url for a submodule is usable across the 
group. By offering the *option* (and it is only an option) to make the 
urls relative to the super-project, the super-project can be usefully 
shared.

Instead they can decide themselves by editing .git/config between "git submodule
init" and "git submodule update", or by branching .gitmodules.
  

Yes, a person can edit .gitmodules, or can edit .git/config, in order to 
tell git where things are. But why should they *have* to when relative 
urls will suffice and git can take care of this transparently.

If you source git-parse-remote, you can use

                realrepo="$(get_remote_url "$(get_default_remote)")$repo"

Mike
  

Yes, the patch itself can be improved, am sending a revised one.

Mark