Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)

From: Finn Arne Gangstad <finnag@pvv.org>
Date: Mar 24, 2009, 11:16 UTC
Message-ID: <20090324111645.GA6084@pvv.org>
In-Reply-To: <7vhc1j2si9.fsf@gitster.siamese.dyndns.org>

On Tue, Mar 24, 2009 at 02:13:18AM -0700, Junio C Hamano wrote:

Show 21 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> 
> >   $ git push --dry-run sf.net
> >   warning: You did not specify any refspecs to push, and the current remote
> >   warning: has not configured any push refspecs. The default action in this
> >   warning: case is to push all matching refspecs, that is, all branches
> >   warning: that exist both locally and remotely will be updated.  This may
> >   warning: not necessarily be what you want to happen.
> >   warning:
> >   warning: You can specify what action you want to take in this case, and
> >   warning: avoid seeing this message again, by configuring 'push.default' to:
> >   warning:   'nothing'  : Do not push anythig
> >   warning:   'matching' : Push all matching branches (default)
> >   warning:   'tracking' : Push the current branch to whatever it is tracking
> >   warning:   'current'  : Push the current branch
> >   fatal: 'sf.net' does not appear to be a git repository
> >   fatal: The remote end hung up unexpectedly
> >
> > The final, most important error messages are dwarfed out by the warning
> > that talks about setting configuration on the remote that does not even
> > exist.

I actually agree, but that final error is printed in a very ugly place! It would require some surgery to pause the warning until we figure out that sf.net is not a valid remote in the current setup.

get_refs_via_connect->connect_setup->git_connect-> .. fork()s .., runs
   "sh -c git-receive-pack 'sf.net'" (which prints the first error)
and get_remote_heads->packet_read_line->safe_read() dumps the final error
and dies.

Is there any reason why remote_get needs to return a valid remote for a value like "sf.net"? If it didn't, the error message would be even better, and not complain about a "remote end".

Just thinking aloud, if what is specified as a remote does not contain a ":" it cannot really be a URL(?), and we can assume it is a local directory. If that directory does not exist is not a valid git repository, it might be safe to fail in remote_get?

- Finn Arne