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