Re: message on no-args push to an empty repo

From: Jeff King <peff@peff.net>
Date: Mar 14, 2010, 20:54 UTC
Message-ID: <20100314205409.GB31564@coredump.intra.peff.net>
In-Reply-To: <2e24e5b91003121759k34ec294cl8a57ef22eda2bbf5@mail.gmail.com>

On Sat, Mar 13, 2010 at 07:29:21AM +0530, Sitaram Chamarty wrote:

Show 9 quoted lines

> When someone is doing the *first* push to an empty remote repo, and
> they try to use the no-args "git push", they get this:
> 
> > No refs in common and none specified; doing nothing.
> > Perhaps you should specify a branch such as 'master'.
> > fatal: The remote end hung up unexpectedly
> > error: failed to push some refs to 'git@gitsrv:testsite.git'
> 
> This is a fairly clear message, except that by only mentioning the

Actually, I think that message could be improved in several ways. It looks like it is triggered any time we have nothing to push. But "no refs in common" is specifically about the matching behavior, which these days may not even have been invoked (e.g., if I set push.default).

Also, since this is the error path, I don't see a problem in spending a few extra cycles to come up with a more specific error message. In particular, it may help users to distinguish between "you have no commits" and "you have nothing matching". In the former case, there is no useful push command to issue, and we should tell them so. In the latter, they should probably issue "git push $remote HEAD".

And as you noted later, it doesn't really tell them what push command to do at all. Any advice should probably be in the form of "try this cut-and-pastable command."

Show 7 quoted lines

> > $ git push master
> >
> > fatal: 'master' does not appear to be a git repository
> > fatal: The remote end hung up unexpectedly
> 
> The correct answer of course is "git push origin master", and yes I
> realise they should read the git-push manpage...

It would be nice if this message was better, too, but that is harder. receive-pack generates the first line, and then just hangs up (and push generates the second message). But the user can't even tell which end produced what message.

It may be that we can give better advice from the pushing side if the remote end hangs up unexpectedly before saying anything. But I suspect there are a lot of corner cases for such advice (off the top of my head, receive-pack wasn't found, ssh didn't connect, tcp didn't connect, bad hostname, bad remote name, typo in git repository name, etc).

-Peff