Re: Random thoughts on "upstream"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]