Junio C Hamano wrote:
> 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).
My problem with this entire scheme _is_ the magic push.default =
single. Currently, push.default only kicks in when no
remote.<name>.push refspec is specified (in other words, it is a
default value of remote.<name>.push for all remotes), and I don't
think we should change this. If the user wants to configure the push
refspec (either for rewriting, or for determining what to push), there
is exactly one thing to change: remote.<name>.push. So I can have:
[remote "theodore"]
push = master
push = +pu
This means that I will always push master without force and pu with
force, irrespective of the branch I'm on.
[remote "origin"]
push = refs/heads/*:refs/heads/rr/*
This means that I will always push all branches without force with
rewriting, irrespective of the branch I'm on.
[remote "ram"]
push = HEAD:refs/heads/rr/%1
This means that I will always push the current branch without force,
with rewriting.
[remote "felipe"]
# empty
This means that remote."felipe".push falls back to the refspec
specified by push.default.
Isn't branch.<name>.push is completely unnecessary? Does this make
sense to you? Isn't it more straightforward and general (how do I get
a push.default = single on a per-remote basis) than your solution?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
