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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 15, 2013, 22:56 UTC
Message-ID: <CAMP44s1kWkNgFMAvThczCvTZppWGca0YvGv=CQ15GtViA1zy_Q@mail.gmail.com>
In-Reply-To: <7vzjvvanro.fsf@alter.siamese.dyndns.org>

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

Show 7 quoted lines

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> The 'base' branch will be set each time you create a branch from another;
>> 'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.
>
> "git checkout -t -b foobar mastee" would instead set 'upstream' of
> 'foobar' to the branch 'master' of remote '.' (the current one).

Yeah, but I don't to set an upstream, because 'master' is not the upstream of 'foobar'.

> This 'base' is a new mechanism to explicitly say "The upstream of
> this branch lives locally" by not setting "branch.foobar.remote".

No, 'base' can point to a remote tracking branch.

Show 8 quoted lines

>> Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and Git will
>> pick the right branch to rebase unto, even if you have no 'upstream'
>> configured.
>
> Surely you can teach rebase to pay attention to 'base' and achieve
> that.  But you can already do so with upstream, so this is not an
> advertisement of a 'plus', but rather a lack of 'minus' (which is
> not a bad thing at all).

Only if there's an upstream configured, which many times is not the case, and many times causes side-effects the user doesn't want to.

The purpose of 'upstream' is completely different.

Show 15 quoted lines

>> This way 'git fetch' will keep picking 'origin', and other commands that make
>> use of 'upstrem' would be undisturbed.
>
> And this is the true plus, because 'git fetch' with the current
> "setting a local base using the same upstream mechanism to point at
> a branch of _this_ repository, indirectly setting the upstream
> _repository_ for this branch to the current repository" will end up
> making you fetch from yourself, which is not very interesting.
>
> So I think I understand your itch and I agree that it is a valid
> one.
>
> I however am not yet convinced if that direction is what you really
> want go in, though.  What should your 'git pull' on that branch do,
> for example?

Exactly the same as 'git pull' does right now.

'base' has absolutely nothing to do with pulling or pushing.

Show 11 quoted lines

> When you are on foobar and want to integrate with the branch you
> based your work on (i.e. local 'master'), you can do one of these:
>
>     $ git pull
>     $ git pull --rebase
>
> to "fetch the upstream branch and integrate with it", without having
> to even care if that upstream branch is from the remote, or happens
> to be truly local.  By making 'git fetch' to go to the remote origin
> site, what will you be merging (or rebasing on) when you do the
> above two?

The same as we do now.

Show 7 quoted lines

> Incidentally, I suspect you can do exactly the same thing without
> introducing a new concept "base" and instead special casing a remote
> whose URL is "."; you essentially declare that "The upstream of this
> branch whose branch.$name.remote is set to '.' lives locally", which
> is not all that different from saying "The upstream of this branch
> whose branch.$name.base exists lives locally", which is what you
> seem to be proposing.

That would be good, but it doesn't have the same benefits:

If I have set an 'upstream' branch, say 'github/master', and I have 'base' branch, say 'origin/master'. I would expect 'git rebase' to rebase onto 'origin/master'. When I do 'git push', I expect to push to 'github/master'. Moreover, I would expect 'git fetch' to fetch from 'origin', but that can be discussed later.

Right now I'm forced to choose a single branch and set it to 'upstream'. If I choose 'origin/master' (which is not really the upstream), the rebase would do what I want, but not the push, unless I have configured a remote.pushdefault, but that would only work if I the real upstream is the common one. If I choose 'github/master', then rebase would not do what I want (and neither would fetch).

Show 9 quoted lines

> One of the things this alternative approach
> would "special case" such remote is probably to cause "git fetch" to
> ignore such a branch.$name.remote setting and instead go fetch from
> 'origin', just like your "if there is branch.$name.base, but no
> branch.$name.remote, fetch will go to 'origin'" does.
>
> But it has exactly the same "what happens when you do 'git pull'"
> problem, so even though it is conceptually a lot simpler, it has the
> same brokenness.

There is no brokenness; 'git pull' does different things depending on the configuration. With my proposal nothing would change.

-- 
Felipe Contreras