Re: git push remote syntax

From: Jeff King <peff@peff.net>
Date: Nov 7, 2016, 21:01 UTC
Message-ID: <20161107210107.d6c7ihmi5npwm76i@sigill.intra.peff.net>
In-Reply-To: <1613741.x6i0st30av@localhost.localdomain>

On Mon, Nov 07, 2016 at 01:49:40PM +0000, Diggory Hardy wrote:

> One thing I find a little frustrating about git is that the syntax needed 
> differs by command. I wish the 'remote/branch' syntax was more universal:

The reason it's not is that "remote/branch" refers to a branch in your local repository. Whereas fetch/push want a single remote, and then one or more refspecs. They often _look_ the same in simple cases, but the latter covers a lot of cases not handled by the former.

For example:

  # no configured remote nor remote tracking branch at all
  git pull git://host/repo.git master

  # multiple branches for an octopus merge
  git pull origin branchA branchB

  # refspecs
  git pull origin devel:tmp

It's possible that we could have some kind of do-what-I-mean syntax for the command-line options, though. It wouldn't have to cover every esoteric case, but could cover the common ones and expand into the more complete syntax. E.g., if we made:

  git pull origin/master

behave as if you said:

  git pull origin master

that would cover many uses. There are still some corner cases, though:

  - you could have a remote with a slash in it; presumably we would
    check that first and fallback to the DWIM behavior

  - These commands only handle a single remote at once, so something
    like:

      git pull origin/foo other-remote/bar

    is nonsensical. We'd have to catch and disallow multiple remotes.
    Probably we could only kick in the DWIM when there is a single
    argument (otherwise you're just repeating the remote name over and
    over, at which point you might as well use the "remote [refspec...]"
    syntax.

It seems like it's probably do-able.

I'm still undecided on whether it is a good idea or not. In one sense, it does unify the syntax you use to refer to a remote branch. But it also blurs the meanings. Normally "origin/master" refers only to your local refs/remotes copy of what is on the remote, but this is blurring the line. It's not clear to me if that reduces confusion (because you don't have to care about that line anymore), or if it increases it (because sometimes it _does_ matter, and somebody who doesn't learn the difference between the two will get bitten later. Plus now there are multiple ways of spelling the same thing).

> > git pull myremote/somebranch
> complains about the syntax; IMO it should either pull from that branch (and 
> merge if necessary) or complain instead that pulling from a different branch 
> is not supported (and suggest using merge).

Reading this, I wonder if I've misinterpreted your request. It sounds like you want this to be the same as:

  git merge myremote/somebranch

which is at least consistent in the use of "remote/branch" syntax. But weird, because you're asking "pull" not to pull. Or another way to think of it is that "git pull foo/bar" effectively becomes "git pull . foo/bar". Which seems like it may be potentially error-prone, especially if you use slashes in your remote names.

-Peff