Re: Relative submodule URLs

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 19, 2014, 16:39 UTC
Message-ID: <xmqqiolowi1f.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAHd499CJfX_n_KnQScTFueCSkj6i0x0ozwwD8Oe_2a-VH2oq1w@mail.gmail.com>

Robert Dailey <rcdailey.lists@gmail.com> writes:

Show 5 quoted lines

> 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?