Ramkumar Ramachandra [off-list ref] writes:
Junio C Hamano wrote:
quoted
quoted
# on branch master, derived from origin
$ git push ram
And branch.master.push is set to next? Will you let her shoot herself
in the foot like this?
It is not shooting in the foot, if branch.master.push is explicitly
set to update next. I do not see any issue in that part.
The question does not pertain to master being mapped to next; it
pertains to central-workflow versus triangular-workflow: origin versus
ram. If the user has set push.default to upstream, she _expects_
triangular pushes to always be denied,...
If the user said "git push" without an explicit request to push to
"ram", and if branch.master.pushremote was not set to "ram", and
still the command "git push" pushed the branch to "ram", then I
would understand what you are worried about, but otherwise I do not
see how what you are saying makes sense.
A safety valve is different from a straight-jacket. If you are
working largely with a central repository and have push.default set
to upstream, are you now disallowed to push out things to other
places to ask help from your colleague to check your wip? Why?
Or are you saying that with push.default set to upstream, only these
two forms should be allowed?
$ git push ;# no destination, no refspec
$ git push there ref:spec ;# both explicitly specified
Junio C Hamano wrote:
If the user said "git push" without an explicit request to push to
"ram", and if branch.master.pushremote was not set to "ram", and
still the command "git push" pushed the branch to "ram", then I
would understand what you are worried about, but otherwise I do not
see how what you are saying makes sense.
We currently have no system to differentiate between those two cases.
A safety valve is different from a straight-jacket. If you are
working largely with a central repository and have push.default set
to upstream, are you now disallowed to push out things to other
places to ask help from your colleague to check your wip? Why?
I've been harping about how this safety valve is poorly done, and I'm
the first person interested in loosening it. But I do not think this
is the way to do it: drop in branch.<name>.push magic, and make
upstream suddenly work with triangular workflows?
Or are you saying that with push.default set to upstream, only these
two forms should be allowed?
$ git push ;# no destination, no refspec
$ git push there ref:spec ;# both explicitly specified
No, no. What I meant is:
From the documentation of push.default, I _expect_ upstream to kick
in only in the first case. In the second case, I _know_ that my
push.default is inconsequential.
With branch.<name>.push magic, you've sneaked in a push refspec under
the carpet, and the first form suddenly doesn't care about
push.default anymore. remote.<name>.push is also an under-the-carpet
implementation that I don't like: it's done in push_with_options()
which can completely bypass setup_default_push_refspecs(), shooting
the user in the face.
I want properly defined precedence and well-defined overall behavior.
Not sneaky stuff. I don't have an answer, but will start a discussion
with some code soon. In the meantime, since we've already figured out
this series, merge it without 6/6.
Thanks.