Re: [RFC] New kind of upstream branch: base branch

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 15, 2013, 23:32 UTC
Message-ID: <CAMP44s3AwODeOE-D+xYyBQzu4TQfbs1P1N6tG4CW9w5LPH424A@mail.gmail.com>
In-Reply-To: <7vr4h7al9k.fsf@alter.siamese.dyndns.org>

On Wed, May 15, 2013 at 6:14 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 11 quoted lines

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Exactly the same as 'git pull' does right now.
>
> You set
>
>         [branch 'foobar']
>                 base = refs/heads/master
>
> then 'git pull [--rebase]' will go to 'origin' due to the default,
> but then what branch from the 'origin' are you integrating with?

The same as if you didn't have 'branch.foobar.base': none. You get an error because there's no upstream.

Show 20 quoted lines

> Do you mean you are also setting both remote and upstream, perhaps
> like this, for all of your branches?
>
>         [remote "origin"]
>                 url = github.com:maintainer/hisproject
>                 fetch = +refs/heads/*:refs/remotes/origin/*
>
>         [remote "github"]
>                 url = github.com:felipec/myproject
>                 fetch = +refs/heads/*:refs/remotes/github/*
>
>         [branch 'foobar']
>                 base = refs/heads/master
>                 remote = github ;# or is it origin???
>                 upstream = refs/heads/foobar
>
> Then your 'git pull' will fetch from remote 'origin' and integrate
> with its 'foobar' and 'push' may go to update 'foobar' at 'github'.
>
> Perhaps that is what you meant.

That's what I described in my example.

Show 7 quoted lines

>> 'base' has absolutely nothing to do with pulling or pushing.
>
> I agree it shouldn't have anything to do with pushing, but given
> that 'git pull [--rebase]' is a way to do a 'merge' or 'rebase' with
> what you 'git fetch', introducing something that 'merge' or 'rebase'
> pays attention to that does not have anything to do with 'pull'
> sounds like it breaks existing end user expectation.

But it's already broken.

'git pull' is not the same as 'git fetch'+'git merge'. That *only* works when merge.defaulttoupstream is set.

> But that does not mean it is a bad idea. The behaviour changes only
> when you have branch.$name.base, so I suspect that we do not need to
> worry about "what if the user has both?" case you mentioned in your
> first message.

Indeed. It wouldn't be an intrusive change; it would only affect 'git rebase', and nothing more.

But I'm wondering if the behavior of 'git fecth' should change as well. And in fact it should be the other way around.

Show 7 quoted lines

> I think I misunderstood what you meant.  If it is the norm to have
> both base and upstream/remote in branch.$name (as opposed to "have
> only branch.$name.base and not branch.$name.remote to force fetch to
> go to the default 'origin'), then 'git pull' will not break and I
> can see how many things would work naturally (admittedly I can only
> say 'many things', not 'everything', at this point, as I haven't
> thought things through).

But I think the norm would be to have only 'base', because a lot of people don't manually set an upstream branch.

In the end it all boils down to; which is the upstream 'origin/master', or 'github/master'? Well, it is 'origin/master', so 'upstream' should point there, but I don't want to push to the 'upstream', I want to push somewhere else by default.

-- 
Felipe Contreras