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

From: Mark Levedahl <mlevedahl@gmail.com>
Date: Sep 24, 2007, 02:27 UTC
Message-ID: <46F7209C.2030205@gmail.com>
In-Reply-To: <loom.20070924T002011-331@post.gmane.org>

Michael Smith wrote:

Show 8 quoted lines

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

Show 6 quoted lines

> 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