{"thread":{"id":"44435","subject":"git push remote syntax","startedAt":"2016-11-07T13:56:13Z","lastAt":"2016-11-07T21:01:14Z","messageCount":2,"participants":["Diggory Hardy","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"305485","messageId":"1613741.x6i0st30av@localhost.localdomain","threadId":"44435","inReplyTo":null,"subject":"git push remote syntax","fromName":"Diggory Hardy","fromEmail":"lists@dhardy.name","sentAt":"2016-11-07T13:49:40Z","receivedAt":"2016-11-07T13:56:13Z","isPatch":false,"sender":{"key":"lists@dhardy.name","avatar":null},"body":"Dear all,\n\nOne thing I find a little frustrating about git is that the syntax needed \ndiffers by command. I wish the 'remote/branch' syntax was more universal:\n\n> git pull myremote/somebranch\ncomplains about the syntax; IMO it should either pull from that branch (and \nmerge if necessary) or complain instead that pulling from a different branch \nis not supported (and suggest using merge).\n\n> git push myremote/somebranch\nshould push there, i.e. be equivalent to\n> git push myremote HEAD:somebranch\n\nThese are just some comments about how I think git could be made easier to \nuse. Apologies if the suggestions have already been discussed before.\n\nRegards,\n\nD Hardy\n"},{"id":"305512","messageId":"20161107210107.d6c7ihmi5npwm76i@sigill.intra.peff.net","threadId":"44435","inReplyTo":"1613741.x6i0st30av@localhost.localdomain","subject":"Re: git push remote syntax","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-11-07T21:01:07Z","receivedAt":"2016-11-07T21:01:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 07, 2016 at 01:49:40PM +0000, Diggory Hardy wrote:\n\n> One thing I find a little frustrating about git is that the syntax needed \n> differs by command. I wish the 'remote/branch' syntax was more universal:\n\nThe reason it's not is that \"remote/branch\" refers to a branch in your\nlocal repository. Whereas fetch/push want a single remote, and then one\nor more refspecs. They often _look_ the same in simple cases, but the\nlatter covers a lot of cases not handled by the former.\n\nFor example:\n\n  # no configured remote nor remote tracking branch at all\n  git pull git://host/repo.git master\n\n  # multiple branches for an octopus merge\n  git pull origin branchA branchB\n\n  # refspecs\n  git pull origin devel:tmp\n\nIt's possible that we could have some kind of do-what-I-mean syntax for\nthe command-line options, though. It wouldn't have to cover every\nesoteric case, but could cover the common ones and expand into the more\ncomplete syntax. E.g., if we made:\n\n  git pull origin/master\n\nbehave as if you said:\n\n  git pull origin master\n\nthat would cover many uses. There are still some corner cases, though:\n\n  - you could have a remote with a slash in it; presumably we would\n    check that first and fallback to the DWIM behavior\n\n  - These commands only handle a single remote at once, so something\n    like:\n\n      git pull origin/foo other-remote/bar\n\n    is nonsensical. We'd have to catch and disallow multiple remotes.\n    Probably we could only kick in the DWIM when there is a single\n    argument (otherwise you're just repeating the remote name over and\n    over, at which point you might as well use the \"remote [refspec...]\"\n    syntax.\n\nIt seems like it's probably do-able.\n\nI'm still undecided on whether it is a good idea or not. In one sense,\nit does unify the syntax you use to refer to a remote branch. But it\nalso blurs the meanings. Normally \"origin/master\" refers only to your\nlocal refs/remotes copy of what is on the remote, but this is blurring\nthe line. It's not clear to me if that reduces confusion (because you\ndon't have to care about that line anymore), or if it increases it\n(because sometimes it _does_ matter, and somebody who doesn't learn the\ndifference between the two will get bitten later. Plus now there are\nmultiple ways of spelling the same thing).\n\n> > git pull myremote/somebranch\n> complains about the syntax; IMO it should either pull from that branch (and \n> merge if necessary) or complain instead that pulling from a different branch \n> is not supported (and suggest using merge).\n\nReading this, I wonder if I've misinterpreted your request. It sounds\nlike you want this to be the same as:\n\n  git merge myremote/somebranch\n\nwhich is at least consistent in the use of \"remote/branch\" syntax. But\nweird, because you're asking \"pull\" not to pull. Or another way to think\nof it is that \"git pull foo/bar\" effectively becomes \"git pull .\nfoo/bar\". Which seems like it may be potentially error-prone, especially\nif you use slashes in your remote names.\n\n-Peff\n"}]}