From: Mark Levedahl Date: Mon, 24 Sep 2007 02:27:40 GMT Subject: Re: [PATCH] git-submodule - allow a relative path as the subproject url Message-ID: <46F7209C.2030205@gmail.com> In-Reply-To: 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