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

[Mark Levedahl <mlevedahl@gmail.com>]

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