message on no-args push to an empty repo

message on no-args push to an empty repo

[Sitaram Chamarty]

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

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

[Jeff King]

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

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

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