Re: [ITCH] Specify refspec without remote

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 10, 2013, 21:42 UTC
Message-ID: <CALkWK0m=iDw+N0zcfEEt1jzFD4wOOzLgyBWNyc=HZ+xLe5SBLw@mail.gmail.com>
In-Reply-To: <20130410212911.GE27070@google.com>

Jonathan Nieder wrote:

Show 6 quoted lines

> My first hunch is not to like this, since it means
>
>         git push -- master next
>
> might push to two different remotes and because it's not obvious
> to me when it would be useful.

Yes, it will push to two different remotes.  And why is it not useful?
 If we also had something corresponding to branch.<name>.merge for
push*, I would argue that this and branch.<name>.pushremote together
define how a branch should be pushed, independent of everything else.
Like I said earlier, I don't think of a git repository as a whole, but
rather a collection of upstream and forked branches.  Every branch is
always fetched  from its upstream (might or might not be the same as
fork) using branch.<name>.remote, and pushed to its fork using
branch.<name>.pushremote.  A git push; can use the context of the
current branch to select branches (along with their configurations) to
push, nothing more.  It should not apply the configuration of the
current branch to the other branches that it's pushing; that's just
wrong.

* Can we write this branch.<name>.pushmap, effectively overriding
branch.<name>.merge when in push.default = upstream and simple?