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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html