Robert Dailey <rcdailey.lists@xxxxxxxxx> writes: > 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. Keeping 'origin' pointing at the repository where you cloned from, without doing anything funky (i.e. "set up my remote") would give you convenient pulls. > - git push :: If I want convenient pushes, track my origin branch. > Pulls become less convenient. My relative submodules will now need to > be forked. You need to configure your pushes to go to a different place, if you want them to go to a different place ;-). Long time ago, it used to be that you have to affect the URL used in both direction, making pulls less conveninent, but hasn't this been made an non-issue for triangular workflows with the introduction of remote.pushdefault long time ago? > - git submodule update :: I track upstream to avoid forking my > submodules. But pushes become more inconvenient. If 'submodule update' follows the same place as 'pull' goes by default, I would imagine that there is no issue here, no? Am I oversimplifying the issue by guessing that the root cause of is that you are not using remote.pushdefault from your configuration toolchest and instead setting the 'origin' to a wrong (i.e. where push goes) place? -- 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