On Tue, Aug 19, 2014 at 2:30 PM, Heiko Voigt <hvoigt@xxxxxxxxxx> wrote: > Well the remote for the submodule is currently only calculated once, > when you do the initial > > git submodule update --init > > that clones the submodule. Afterwards the fixed url is configured under > the name 'origin' in the submodule like in a normal git repository that > you have freshly cloned. Which remote is used for cloning depends on the > configured remote for the current branch or 'origin'. > > When you do a fetch or push with --recurse-submodules it only executes a > 'git fetch' or 'git push' without any specific remote. For fetch the > same commandline options (but only the options) are passed on. > > Here it might make sense to guess the remote in the submodule somehow > and not do what fetch without remotes would do. > > For the triangular workflow not much work has been done in regards to > submodule support. > > But since a submodule behaves like a normal git repository maybe there > is not much work needed and we can just point to the workflow without > submodules most times. We still have to figure that out properly. Maybe then the only thing we need is a --with-remote option for git submodule? :: git submodule update --init --with-remote myremote The --with-remote option would be a NOOP if it's already initialized, as you say. But I could create an alias for this as needed to make sure it is always specified. That way, just in case someone cloned with their fork (in which case 'origin' would not be pointing in the right place), they could tell it to use `myremote`. This is really the only strange case to handle right now (people that clone their forks instead of the actual upstream/central repository). -- 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