Re: [bug-ish] [convenience] fatal: only [12] (reference)s? expected, [12] given

[Stefan Beller <sbeller@google.com>]

On Wed, May 30, 2018 at 1:12 AM, mana vortex <manavortex@gmail.com> wrote:
> Hello git folks,
> I’m writing about something that annoys me since forever: The reference
> handling is not consistent between commands. For example, I do
>
> git checkout origin master

  $ git checkout origin master
  error: pathspec 'master' did not match any file(s) known to git.

(I am running a recent build of the next branch,
which version do you run?)

If I do
  git checkout or<TAB>
it auto-completes to
  git checkout origin/
which I can then type master after and it works with origin/master

> but I do
>
> git reset —hard origin/master

That worked for me, and the whitespaced version fails as:
  $ git reset --hard origin master
  fatal: Cannot do hard reset with paths.

I do not understand the problem, yet, as for these two commands
you'd want to give <remote>/<branch> with the slash in between.

> I always get it wrong the first time.

What exactly? The confusion with slash or whitespace?

> Is there a convenience option that circumvents the error?

I think understanding the Git model would help with that:

The only commands that need a whitespace between origin and
master I can think of are push and fetch. These two commands
are commands that use the network to directly talk to the specified
remote and the second argument "master" is just a short form of a
refspec, typed out long it would be "refs/heads/master:refs/heads/master"
which specifies the branch (with full prefix) once on the sending side
and once on the receiving side, separated by colon.

And for these commands we actually talk to the remote.
For all other commands we use the locally cached version of the
branch that we think the remote has, so the "origin" is just a prefix
in the namespace of branches, indicating that all branches under
"origin/" are "remote tracking branches", i.e. these local cached branches.

> If one argument is given, but two are expected, split the argument at the
> first / and retry - throw error if that isn’t valid
> If two arguments are given, but one is expected, concat the arguments with a
> /.
>
> Is that possible already, and if not, would you care to implement it?

I think that would make for hilarious error messages in corner cases;
I am not sure if we want to water down the difference of a remote + refspec
and a local remote tracking branch, such that it is harder to understand?

Thanks,
Stefan