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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
