On Fri, Apr 11, 2014 at 08:48:01AM -0500, Felipe Contreras wrote:
> I think of @{publish} as "the branch the user has configured to push
> to"; it overrides all other configurations (push.default and push
> refspecs). I wouldn't mind having a @{push} *in addition* to @{publish}
> that would have the behavior you mention, but for @{publish} I'm pretty
> certain the behavior I want is that it maps *directly* to what the user
> has configured.
I guess I don't understand why we need "branch.*.push" when we already
have push refspecs that do the same thing (and are more powerful, as
they can glob).
The behavior you describe is not useful to me, as it would mean having
to manage branch.*.push as a duplicate of the information that is
already found in "remote.$(git config remote.pushdefault).push". I do
not mind if the two co-exist, but please do not take the short @{p} as
your series does (not only because of @{push}, but also because @{pull}
has been mentioned elsewhere as a possible other name for @{upstream}).
-Peff
--
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