Re: Random thoughts on "upstream"

[Junio C Hamano <gitster@pobox.com>]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> I suspect that the issue you're trying to address is:
>
> [remote "ram"]
>     push = refs/heads/*:refs/heads/rr/*
>
> not dictating which refs to push when I say 'git push' (it'll push all
> the refs under refs/heads/*, not respecting push.default=current in my
> scheme).

That is not what I was addressing.  You outlined your scenario as
"you were not, but you are now, allowed to push an approved ref into
'origin'".  And you do so under a different name.  That is why I set
that rr/ renaming push refspec for a remote ORIGIN not RAM.

And that was done with extensivility your example implied in mind:
you may later be allowed to push other branches as well to origin.
That is why the refspec definition for 'origin' does not hardcode
the name of the branch you are permitted to push there at this
moment.  The fact that hot-branch goes to origin is encapsulated in
the branch.hot-branch.pushremote.  The rule, under which the name of
any branch that goes to the origin is renamed, is encapsulated in
remote.origin.push refspec (the introduction of the new mode
"push.default = single" is necessary to make this work).

When making that change, our fictitious ram did not have to touch
"remote.ram.push" *at all*.  Independent of what the owner of
"origin" and ram agreed in that example, ram would keep doing
exactly the same thing to his own publishing point so that people
who are working off of his work would get updates from the place
known to contain his work from before.

So with "git push ram", it will push everything to "ram" under the
same name *without* rr/ renaming, but that was *by design*, not
something I wanted to or I needded to work around.  And you would
also push to "origin" by doing "git push" while on hot-topic branch.