Re: Cryptic error messages?

From: Jeff King <peff@peff.net>
Date: Apr 22, 2009, 21:23 UTC
Message-ID: <20090422212351.GB16096@coredump.intra.peff.net>
In-Reply-To: <7vws9c1jdz.fsf@gitster.siamese.dyndns.org>

On Wed, Apr 22, 2009 at 02:14:00PM -0700, Junio C Hamano wrote:

Show 9 quoted lines

> > Actually, this is not true. receive-pack actually passes the error code
> > back to send-pack, which prints it. I think it is doing so because we
> > get that status separate from the individual ref status. But if you look
> > at receive-pack, it doesn't even bother trying individual refs if the
> > unpack failed; every ref will just get the "unpack failed" message.
> 
> How could it even "bother" to tell which ref?  The protocol says "Here are
> the values for the refs after you unpack the data that follows; here is
> the pack data for you", and then you find the error in the pack data.

Sorry, I don't understand. The errors are coming from receive-pack, so it sends:

  unpack <some error code>\n
  ng refs/heads/whatever n/a (unpacker error)\n

So what I mean is that receive-pack doesn't actually _do_ anything per-ref after the unpacker error. If there is an unpacker error, then it _always_ will say "n/a (unpacker error)".

So I wonder if it would be nicer for send-pack not to spew "unpack error: <blah blah>" to stderr, and instead put something meaningful into the status table, which is where people are expecting to find error codes. Even if it is repetitious. IOW, something like:

  To git://blah/blah
   ! [remote rejected] foo -> foo (unpacker exited with error code)

or if you are pushing several refs:

  To git://blah/blah
   ! [remote rejected] foo -> foo (unpacker exited with error code)
   ! [remote rejected] bar -> bar (unpacker exited with error code)

-Peff