{"thread":{"id":"48599","subject":"[bug-ish] [convenience] fatal: only [12] (reference)s? expected, [12] given","startedAt":"2018-05-30T08:13:49Z","lastAt":"2018-05-30T18:11:14Z","messageCount":2,"participants":["mana vortex","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"348792","messageId":"1B7D3974-AA1C-42B5-A7F5-C5A36B28C34F@gmail.com","threadId":"48599","inReplyTo":null,"subject":"[bug-ish] [convenience] fatal: only [12] (reference)s? expected, [12] given","fromName":"mana vortex","fromEmail":"manavortex@gmail.com","sentAt":"2018-05-30T08:12:41Z","receivedAt":"2018-05-30T08:13:49Z","isPatch":false,"sender":{"key":"manavortex@gmail.com","avatar":null},"body":"Hello git folks,\nI’m writing about something that annoys me since forever: The \nreference handling is not consistent between commands. For example, I do\n\ngit checkout origin master\n\nbut I do\n\ngit reset —hard origin/master\n\nI always get it wrong the first time.\n\nIs there a convenience option that circumvents the error?\n\nIf one argument is given, but two are expected, split the argument at \nthe first / and retry - throw error if that isn’t valid\nIf two arguments are given, but one is expected, concat the arguments \nwith a /.\n\nIs that possible already, and if not, would you care to implement it?\n\nThank you for your time.\n"},{"id":"348825","messageId":"CAGZ79kb6S0NT7YVH6JBV3W+=ikeBJtdbrTK5y_q9hEaGPzpeeQ@mail.gmail.com","threadId":"48599","inReplyTo":"1B7D3974-AA1C-42B5-A7F5-C5A36B28C34F@gmail.com","subject":"Re: [bug-ish] [convenience] fatal: only [12] (reference)s? expected, [12] given","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-05-30T18:11:10Z","receivedAt":"2018-05-30T18:11:14Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, May 30, 2018 at 1:12 AM, mana vortex <manavortex@gmail.com> wrote:\n> Hello git folks,\n> I’m writing about something that annoys me since forever: The reference\n> handling is not consistent between commands. For example, I do\n>\n> git checkout origin master\n\n  $ git checkout origin master\n  error: pathspec 'master' did not match any file(s) known to git.\n\n(I am running a recent build of the next branch,\nwhich version do you run?)\n\nIf I do\n  git checkout or<TAB>\nit auto-completes to\n  git checkout origin/\nwhich I can then type master after and it works with origin/master\n\n> but I do\n>\n> git reset —hard origin/master\n\nThat worked for me, and the whitespaced version fails as:\n  $ git reset --hard origin master\n  fatal: Cannot do hard reset with paths.\n\nI do not understand the problem, yet, as for these two commands\nyou'd want to give <remote>/<branch> with the slash in between.\n\n> I always get it wrong the first time.\n\nWhat exactly? The confusion with slash or whitespace?\n\n> Is there a convenience option that circumvents the error?\n\nI think understanding the Git model would help with that:\n\nThe only commands that need a whitespace between origin and\nmaster I can think of are push and fetch. These two commands\nare commands that use the network to directly talk to the specified\nremote and the second argument \"master\" is just a short form of a\nrefspec, typed out long it would be \"refs/heads/master:refs/heads/master\"\nwhich specifies the branch (with full prefix) once on the sending side\nand once on the receiving side, separated by colon.\n\nAnd for these commands we actually talk to the remote.\nFor all other commands we use the locally cached version of the\nbranch that we think the remote has, so the \"origin\" is just a prefix\nin the namespace of branches, indicating that all branches under\n\"origin/\" are \"remote tracking branches\", i.e. these local cached branches.\n\n> If one argument is given, but two are expected, split the argument at the\n> first / and retry - throw error if that isn’t valid\n> If two arguments are given, but one is expected, concat the arguments with a\n> /.\n>\n> Is that possible already, and if not, would you care to implement it?\n\nI think that would make for hilarious error messages in corner cases;\nI am not sure if we want to water down the difference of a remote + refspec\nand a local remote tracking branch, such that it is harder to understand?\n\nThanks,\nStefan\n"}]}