message on no-args push to an empty repo

Sitaram Chamarty· Mar 13, 2010, 01:59 UTC · lore

Hello,

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 branch name, and not the remote name, it perhaps confuses people into doing this:

> $ 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...

Can we think of a possible wording change to that message to help this situation? For example, would it be safe to assume the remote would always (in such cases) be "origin" and say:

    Perhaps you should specify the remote and the branch explicitly,
like 'git push origin master'

Regards,

Sitaram

Jeff King· Mar 14, 2010, 20:54 UTC · re: Sitaram Chamarty · lore

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

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