Re: Random thoughts on "upstream"

From: Junio C Hamano <gitster@pobox.com>
Date: May 19, 2013, 05:58 UTC
Message-ID: <7vmwrr1pem.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0kYKZGhthdrb6-7RD_c2A7E9rscAZU3=JHM-4rYre6w=Q@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 16 quoted lines

> Junio C Hamano wrote:
>> Having said that I am not sure where your "not overly fond of" comes
>> from, as I do not see a problem with branch.<name>.push.  The only
>> problem I may have with the approach would arise _only_ if we make
>> it the sole way to allow people push to different names, forcing
>> people who want to push N branches to configure it N times.  Other
>> than that, I think it is an acceptable solution to give per-branch
>> control.
>
> It doesn't strike me as being elegant at all.
>
> [branch "hot-branch"]
>     remote = ram
>     push = refs/heads/for-junio/hot-branch
>
> 1.  I git branch -M for-each-ref and push.  Screwed.

-ECANTSEEWHATYOUMEAN.  Your proofreader is screwed ;-)

Show 9 quoted lines

> 2.  Let's say you give me the thumbs up to write hot-branch to origin.
>  Excitedly, I change the remote to origin.  Now I already have push
> semantics for origin (you obviously want me to write to rr/, so I can
> cooperate with others):
>
> [remote "origin"]
>     push = refs/heads/*:refs/heads/rr/*
>
> Unfortunately, it doesn't kick in unless I change branch.<name>.push.

I thought branch.$name.push is "What ref do I push this out as?"

At this point you have two remotes, me as your upstream, and your publishing point, and remote.pushdefault set to the latter since originally you cannot push to 'origin':

    [push]
        default = simple ;# adopt 2.0 default early
    [remote]
        pushdefault = ram

    [remote "ram"}
	url = github.com:ram/something.git
        fetch = +refs/heads/*:refs/remotes/ram/*
        push = +refs/heads/*:refs/heads/*

    [remote "origin"]
        url = git://git.kernel.org/pub/scm/git/git.git
        fetch = +refs/heads/*:refs/remotes/origin/*

    # assuming you forked from my master
    [branch "hot-branch"]
        remote = origin
        merge = refs/heads/master
   +    pushremote = origin
   +    push = refs/heads/rr/hot-branch

The above pseudo-diff would be the changes you would be making to your configuration when you were asked to push your 'hot-branch' to 'origin' as 'rr/hot-branch', I think.

If somebody implements the "push.default = single" (see the original message you are responding to), then the change might be smaller.

    [push]
   -    default = simple ;# adopt 2.0 default early
   +    default = single

    [remote]
        pushdefault = ram

    [remote "ram"}
	url = github.com:ram/something.git
        fetch = +refs/heads/*:refs/remotes/ram/*
        push = +refs/heads/*:refs/heads/*

    [remote "origin"]
        url = git://git.kernel.org/pub/scm/git/git.git
        fetch = +refs/heads/*:refs/remotes/origin/*
   +    push = +refs/heads/*:refs/heads/rr/*

    # assuming you forked from my master
    [branch "hot-branch"]
        remote = origin
        merge = refs/heads/master
   +    pushremote = origin

> I guess what I'm saying is: refspec semantics are inherent
> properties of the remote, not of the local branch.  Since there is
> no intermediate refs/remotes/* sitting between the remote and
> local branches, this is _not_ like branch.<name>.merge at all.

Somewhat true, if you write this with branch.hot-branch.push without push.default=single implicitly introduces

	refs/heads/hot-branch:refs/heads/rr/hot-branch

refspec to the remote named by branch.hot-branch.pushremote.