{"thread":{"id":"23003","subject":"message on no-args push to an empty repo","startedAt":"2010-03-13T01:59:21Z","lastAt":"2010-03-14T20:54:09Z","messageCount":2,"participants":["Sitaram Chamarty","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"136693","messageId":"2e24e5b91003121759k34ec294cl8a57ef22eda2bbf5@mail.gmail.com","threadId":"23003","inReplyTo":null,"subject":"message on no-args push to an empty repo","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2010-03-13T01:59:21Z","receivedAt":"2010-03-13T01:59:21Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"Hello,\n\nWhen someone is doing the *first* push to an empty remote repo, and\nthey try to use the no-args \"git push\", they get this:\n\n> No refs in common and none specified; doing nothing.\n> Perhaps you should specify a branch such as 'master'.\n> fatal: The remote end hung up unexpectedly\n> error: failed to push some refs to 'git@gitsrv:testsite.git'\n\nThis is a fairly clear message, except that by only mentioning the\nbranch name, and not the remote name, it perhaps confuses people into\ndoing this:\n\n> $ git push master\n>\n> fatal: 'master' does not appear to be a git repository\n> fatal: The remote end hung up unexpectedly\n\nThe correct answer of course is \"git push origin master\", and yes I\nrealise they should read the git-push manpage...\n\nCan we think of a possible wording change to that message to help this\nsituation?  For example, would it be safe to assume the remote would\nalways (in such cases) be \"origin\" and say:\n\n    Perhaps you should specify the remote and the branch explicitly,\nlike 'git push origin master'\n\nRegards,\n\nSitaram\n"},{"id":"136777","messageId":"20100314205409.GB31564@coredump.intra.peff.net","threadId":"23003","inReplyTo":"2e24e5b91003121759k34ec294cl8a57ef22eda2bbf5@mail.gmail.com","subject":"Re: message on no-args push to an empty repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-03-14T20:54:09Z","receivedAt":"2010-03-14T20:54:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 13, 2010 at 07:29:21AM +0530, Sitaram Chamarty wrote:\n\n> When someone is doing the *first* push to an empty remote repo, and\n> they try to use the no-args \"git push\", they get this:\n> \n> > No refs in common and none specified; doing nothing.\n> > Perhaps you should specify a branch such as 'master'.\n> > fatal: The remote end hung up unexpectedly\n> > error: failed to push some refs to 'git@gitsrv:testsite.git'\n> \n> This is a fairly clear message, except that by only mentioning the\n\nActually, I think that message could be improved in several ways. It\nlooks like it is triggered any time we have nothing to push. But \"no\nrefs in common\" is specifically about the matching behavior, which these\ndays may not even have been invoked (e.g., if I set push.default).\n\nAlso, since this is the error path, I don't see a problem in spending a\nfew extra cycles to come up with a more specific error message. In\nparticular, it may help users to distinguish between \"you have no\ncommits\" and \"you have nothing matching\". In the former case, there is\nno useful push command to issue, and we should tell them so. In the\nlatter, they should probably issue \"git push $remote HEAD\".\n\nAnd as you noted later, it doesn't really tell them what push command to\ndo at all. Any advice should probably be in the form of \"try this\ncut-and-pastable command.\"\n\n> > $ git push master\n> >\n> > fatal: 'master' does not appear to be a git repository\n> > fatal: The remote end hung up unexpectedly\n> \n> The correct answer of course is \"git push origin master\", and yes I\n> realise they should read the git-push manpage...\n\nIt would be nice if this message was better, too, but that is harder.\nreceive-pack generates the first line, and then just hangs up (and push\ngenerates the second message). But the user can't even tell which end\nproduced what message.\n\nIt may be that we can give better advice from the pushing side if the\nremote end hangs up unexpectedly before saying anything. But I suspect\nthere are a lot of corner cases for such advice (off the top of my head,\nreceive-pack wasn't found, ssh didn't connect, tcp didn't connect, bad\nhostname, bad remote name, typo in git repository name, etc).\n\n-Peff\n"}]}