On Tue, Aug 19, 2014 at 5:24 AM, Heiko Voigt <hvo...@hvoigt.net> 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 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
- 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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html