git push remote syntax

git push remote syntax

[Diggory Hardy]

Dear all,

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:

> 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).

> git push myremote/somebranch
should push there, i.e. be equivalent to
> git push myremote HEAD:somebranch

These are just some comments about how I think git could be made easier to 
use. Apologies if the suggestions have already been discussed before.

Regards,

D Hardy

Re: git push remote syntax

[Jeff King]

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