From: Jeff King <peff@peff.net>
Date: Wed, 22 Apr 2009 21:23:51 GMT
Subject: Re: Cryptic error messages?
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:

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