Re: [bug-ish] [convenience] fatal: only [12] (reference)s? expected, [12] given
On Wed, May 30, 2018 at 1:12 AM, mana vortex <manavortex@gmail.com> wrote:
Show 5 quoted lines
> 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.
Show 6 quoted lines
> 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
