On Tue, Aug 19, 2014 at 5:24 AM, Heiko Voigt <hvoigt@xxxxxxxxxx> wrote: > I think the OP problem stems from him having a branch that does not have a > remote configured. Since they do not have 'origin' as a remote and > > git submodule update --init --recursive path/to/submodule > > fails. Right? Not exactly. The issue is that there is a tug of war going on between three specific commands (all of which utilize the tracked remote): git fetch git pull git submodule update (for relative submodules) The way I set up my remote tracking branch will be different for each of these commands: - git pull :: If I want convenient pulls (with rebase), I will track my upstream branch. My pushes have to be more explicit as a tradeoff. - git push :: If I want convenient pushes, track my origin branch. Pulls become less convenient. My relative submodules will now need to be forked. - git submodule update :: I track upstream to avoid forking my submodules. But pushes become more inconvenient. As you can see, I feel like we're overusing the single remote setting. Sure, we've added some global settings to set default push/pull remotes and such, but I don't think that is a sustainable long term solution. I like the idea of possibly introducing multiple tracking remotes for various purposes. This adds some additional configuration overhead (slightly), but git is already very config heavy so it might be worth exploring. At least, this feels like a better thing for the long term as I won't be constantly switching my tracking remote for various purposes. Could also explore the possibility of creating "const remotes". If we specify a remote MUST exist for relative submodules, git can create it for us, and fail to operate without it. It's up to the user to map "fork" to "origin" if needed (perhaps add a `git remote clone <source> <new remote>` to assist with this)? Various approaches we can take, but I don't do development on Git so I'm not sure what makes the most sense. -- 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