Hi, On Tue, May 01, 2012 at 10:57:07AM -0700, Junio C Hamano wrote: > "Philip Oakley" <philipoakley@xxxxxxx> writes: > > > Would an alternative be something like: > > git submodule update <module> --from <remote> > > > > so that the user can state which of the current submodule's remotes > > should be used for fetching the desired update. > > Are you assuming that the <remote> in the above example will be different > per invocation for a single user? I would imagine not---it would be more > like "the upstream has this URL in .gitmodules, but this other mirror is > closer to my network environment", i.e. > > cd <module's directory> && git config remote.origin.url $there > > no? Yes I think this is an important point. If we start working on this I would like to emphasize the fork use case Philip brought up. When cloning a forked repository with submodules you always have the problem of changing/adding the forked submodules remotes afterwards. For me it would be more like an additional lookup mechanism of the "official" urls / names. Since I like to stay as close as possible to the upstream repository I usually refrain from changing the .gitmodules file. A changed .gitmodules file with additional urls (possibly some private ones) is not something you can propagate upstream. What I would like is a mechanism that, given a wanted sha1, would lookup the correct remote to clone/fetch from. But, I have to admit that even though thinking about this for some time now, I have not got to a satisfying answer for myself yet. Cheers Heiko -- 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