Re: [ITCH] Specify refspec without remote

From: Jeff King <peff@peff.net>
Date: Apr 10, 2013, 04:13 UTC
Message-ID: <20130410041343.GB795@sigill.intra.peff.net>
In-Reply-To: <7vobdnnpx6.fsf@alter.siamese.dyndns.org>

On Tue, Apr 09, 2013 at 06:19:01PM -0700, Junio C Hamano wrote:

Show 6 quoted lines

> > 	git push -- master next; # push two refs to default remote
> 
> ... or default "push remote" if there is one, I presume?
> 
> As you are giving what to push, I am assuming that
> branch.$name.remote would not come into play in this case.

I would have assumed the opposite. We feed "push" two items: where to push (dst), and what refspecs to push (refs). We may or may not have each item. Here's what's possible today:

  dst=present, refs=present: (case 1)
    push to $dst, using $refs
  dst=present, refs=missing: (case 2)
    push to $dst, using refspecs from remote.$dst.push or push.default
  dst=missing, refs=missing: (case 3)
    push to remote.pushDefault, branch.*.remote, or "origin"; use
    refspecs from remote.$x.push or push.default, where $x is the remote
    we decide to use.

The missing case 4 is obviously:

  dst=missing, refs=present

And I would expect it to select the remote in the same way as case 3. In other words, the "where" and the "what" are orthogonal, and the presence or absence of one does not affect how the other is calculated (with the exception that _if_ we have a configured remote, whether it was specified by the user or calculated, we may use its config if no refspecs are specified).

Do you want to explain your thinking? I'm guessing it has to do with the fact that choosing branch.*.remote is about trying to push to the configured upstream (even though we traditionally do _not_ take into account branch.*.merge when doing so).

Show 8 quoted lines

> > 	git push origin korg --; # push default refspec to 2 remotes, again
> 
> As you are _not_ saying what to push, I would expect
> branch.$name.remote may have to come into the picture, but because
> you are saying where to push, that is not the case.  What does
> "default refspec" mean in this context?  What "git push origin" (no refspecs)
> would push by default will be sent to "origin", and what "git push
> korg" (no refspecs) would push by default will be sent to "korg"?

Yeah, I would expect that each uses its own default refspec. That is, the above command is exactly equivalent to:

  git push origin && git push korg

(possibly without the short-circuit behavior of "&&", but definitely taking both into account in the exit code).

I'd also be fine if we punted on the multiple remotes thing for now. You can accomplish it easily in the shell, as I showed above (and it is not any less efficient, since we have to make two network connections anyway). Jonathan's syntax allows for 0 to N remotes alongside 0 to N refspecs. The interesting new case (to me, anyway) is the 0 remotes, >0 refspecs case. But we don't have to handle >1 remotes now; once we have the syntax in place, we can make it work later when we've decided on the semantics.

-Peff