Re: Relative submodule URLs

From: Robert Dailey <rcdailey.lists@gmail.com>
Date: Aug 19, 2014, 16:50 UTC
Message-ID: <CAHd499B9Wa=Y6P+OD8Ea-6dA4yZSkGZZSR9CwZAM45evDL_Qiw@mail.gmail.com>
In-Reply-To: <xmqqiolowi1f.fsf@gitster.dls.corp.google.com>

On Tue, Aug 19, 2014 at 11:39 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 33 quoted lines

> Robert Dailey <rcdailey.lists@gmail.com> 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?

Maybe I'm misunderstanding something here and you can help me out.

All the reading I've done (mostly github) says that 'upstream' points to the authoritative repository that you forked from but do not have permissions to write to. 'origin' points to the place you push your changes for pull requests (the fork).

Basically the workflow I use is:

- Use 'upstream' to PULL changes (latest code is obtained from the
authoritative repository)
- Use 'origin' to push your branches. Since I never modify the
branches that exist in 'upstream' on my 'origin' (I do everything
through separate personal branches).

That means if I have a branch off of 'master' named 'topic', I will track 'upstream/master' and get latest with 'git pull'. When I'm ready for a pull request, I do 'git push origin' (I use push.default = simple).

According to my understanding, relative submodules work here. But not everyone on my team uses this workflow. Sometimes they track "origin/topic" (if we use my example again). Won't the submodule try to find itself on the fork now?

Basically it seems like what you're advocating is that I need to enforce a policy of "always track upstream" and "never track origin" and "always set remote.pushdefault". Seems a bit error prone...