Cryptic error messages?

Cryptic error messages?

[John Dlugosz]

$ git push
Counting objects: 9, done.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 3.62 KiB, done.
Total 8 (delta 4), reused 0 (delta 0)
Unpacking objects: 100% (8/8), done.
fatal: unresolved deltas left after unpacking
error: unpack failed: unpacker exited with error code
To //tx01fs01/sys/dev/git/repositories/aardvark.git
 ! [remote rejected] dev -> dev (n/a (unpacker error))
error: failed to push some refs to
'//tx01fs01/sys/dev/git/repositories/aardvark
.git'



Huh?  I'm having trouble defending git's reputation.

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

Re: Cryptic error messages?

[Dmitry Potapov]

On Mon, Apr 20, 2009 at 04:18:09PM -0400, John Dlugosz wrote:
> $ git push
> Counting objects: 9, done.
> Compressing objects: 100% (8/8), done.
> Writing objects: 100% (8/8), 3.62 KiB, done.
> Total 8 (delta 4), reused 0 (delta 0)
> Unpacking objects: 100% (8/8), done.
> fatal: unresolved deltas left after unpacking

I think that is the key message...

> error: unpack failed: unpacker exited with error code
> To //tx01fs01/sys/dev/git/repositories/aardvark.git
>  ! [remote rejected] dev -> dev (n/a (unpacker error))
> error: failed to push some refs to
> '//tx01fs01/sys/dev/git/repositories/aardvark
> .git'
> 
> 
> 
> Huh?  I'm having trouble defending git's reputation.

I don't think that information is very helpful. It would be far more
useful to know what version of Git on client and server sides are
running. Also, running "git fsck --full" may be helpful.

I suspect you have a very old Git version on the server side.


Dmitry

RE: Cryptic error messages?

[John Dlugosz]

It's git version 1.6.2.msysgit.0.186.gf7512.  The remote is file based,
so the same copy is being used.  I would suspect that the problem is
with the network.

git fsck always tells me about dangling objects, so that's normal? In
this case, it said something about a broken link.  I just recopied it
from another location.  But, is it possible to delete just the bad
parts, and have a push from others flesh it out again?

> -----Original Message-----
> From: Dmitry Potapov [mailto:dpotapov@gmail.com]
> Sent: Tuesday, April 21, 2009 7:08 AM
> To: John Dlugosz
> Cc: git@vger.kernel.org
> Subject: Re: Cryptic error messages?
> 
> On Mon, Apr 20, 2009 at 04:18:09PM -0400, John Dlugosz wrote:
> > $ git push
> > Counting objects: 9, done.
> > Compressing objects: 100% (8/8), done.
> > Writing objects: 100% (8/8), 3.62 KiB, done.
> > Total 8 (delta 4), reused 0 (delta 0)
> > Unpacking objects: 100% (8/8), done.
> > fatal: unresolved deltas left after unpacking
> 
> I think that is the key message...
> 
> > error: unpack failed: unpacker exited with error code
> > To //tx01fs01/sys/dev/git/repositories/aardvark.git
> >  ! [remote rejected] dev -> dev (n/a (unpacker error))
> > error: failed to push some refs to
> > '//tx01fs01/sys/dev/git/repositories/aardvark
> > .git'
> >
> >
> >
> > Huh?  I'm having trouble defending git's reputation.
> 
> I don't think that information is very helpful. It would be far more
> useful to know what version of Git on client and server sides are
> running. Also, running "git fsck --full" may be helpful.
> 
> I suspect you have a very old Git version on the server side.
> 
> 
> Dmitry

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

Re: Cryptic error messages?

[Jeff King]

On Mon, Apr 20, 2009 at 04:18:09PM -0400, John Dlugosz wrote:

> $ git push
> Counting objects: 9, done.
> Compressing objects: 100% (8/8), done.
> Writing objects: 100% (8/8), 3.62 KiB, done.
> Total 8 (delta 4), reused 0 (delta 0)
> Unpacking objects: 100% (8/8), done.
> fatal: unresolved deltas left after unpacking
> error: unpack failed: unpacker exited with error code
> To //tx01fs01/sys/dev/git/repositories/aardvark.git
>  ! [remote rejected] dev -> dev (n/a (unpacker error))
> error: failed to push some refs to
> '//tx01fs01/sys/dev/git/repositories/aardvark
> .git'
> 
> Huh?  I'm having trouble defending git's reputation.

Yeah, that is horribly cryptic. What is happening is:

  1. send-pack on the local system spawns receive-pack on the
     remote, which in turn spawns unpack-objects as a helper

  2. unpack-objects barfs with

       fatal: unresolved deltas left after unpacking

     to stderr which is the actual useful bit.

  3. receive-pack notices that the unpacker failed, and spews

       error: unpack failed: unpacker exited with error code

     to stderr, in case unpack-objects didn't say anything.

  4. receive-pack also marks the "status" passed back to send-pack
     as "n/a (unpacker error)"

  5. send-pack gives you the usual nice status table with the ugly
     status from receive-pack marked in it, and then says "OK, I failed
     to push".

So making it better is not quite as simple as you might hope, since
there are three processes involved, and none knows that the other has
spewed to stderr already. But I think there is some low-hanging fruit:

  1. There is no point in receive-pack saying anything to stderr about
     the unpacker failing; in most cases, the unpacker already said
     something, and even if it didn't, we are reporting the problem to
     send-pack in the status field.

  2. "n/a (unpacker error)" is unnecessarily cryptic. Yes, the specifics
     of the message are "not available" (which is presumably what the
     n/a stands for), but the user doesn't care. I think something like
     "failed to unpack objects" would be better.

That leaves only the fact that the _specific_ reason the unpacker failed
is not part of the usual status table. Fixing that is actually a little
tricky because of the multiple processes involved (which do not already
have a string-based communications channel between them).

And of course, it's still a bit cryptic to get "unresolved deltas after
unpacking". However, that is one of those messages that _should_ never
come up, unless the sender is pushing a bogus pack. I wouldn't be
surprised if it an msysgit bug.

-Peff

Re: Cryptic error messages?

[Jeff King]

On Wed, Apr 22, 2009 at 04:32:51PM -0400, Jeff King wrote:

>   3. receive-pack notices that the unpacker failed, and spews
> 
>        error: unpack failed: unpacker exited with error code
> 
>      to stderr, in case unpack-objects didn't say anything.

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.

-Peff

Re: Cryptic error messages?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Apr 22, 2009 at 04:32:51PM -0400, Jeff King wrote:
>
>>   3. receive-pack notices that the unpacker failed, and spews
>> 
>>        error: unpack failed: unpacker exited with error code
>> 
>>      to stderr, in case unpack-objects didn't say anything.
>
> 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.

Re: Cryptic error messages?

[Jeff King]

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

RE: Cryptic error messages?

[John Dlugosz]

> Yeah, that is horribly cryptic. What is happening is:
> ...

Thanks for the detailed analysis.  It makes me realize now that I'm looking at a log, not a UI-approved indicator.  Logs are great when you are trying to figure something out, so that sure beats not having that information when it is wanted.

> So making it better is not quite as simple as you might hope, since
> there are three processes involved, and none knows that the other has
> spewed to stderr already.

I see.  That makes me realize that a "lib" approach rather than piping commands has distinct advantages.  In implementing something high-level that calls low-level features, my code has a separate error channel back (e.g. exceptions), not just the return value.  It can arrange the successive levels of detail in the opposite order, allowing the user to drill down to the level of "tell me something I don't know".  It can extract information from the error and reformulate its own error or take different actions.

What we are seeing here is an error log, not an exception.




 But I think there is some low-hanging fruit:
> 
>   1. There is no point in receive-pack saying anything to stderr about
>      the unpacker failing; in most cases, the unpacker already said
>      something, and even if it didn't, we are reporting the problem to
>      send-pack in the status field.
> 
>   2. "n/a (unpacker error)" is unnecessarily cryptic. Yes, the
> specifics
>      of the message are "not available" (which is presumably what the
>      n/a stands for), but the user doesn't care. I think something like
>      "failed to unpack objects" would be better.


So you would wind up with something like:
> $ git push
> Counting objects: 9, done.
> Compressing objects: 100% (8/8), done.
> Writing objects: 100% (8/8), 3.62 KiB, done.
> Total 8 (delta 4), reused 0 (delta 0)
> Unpacking objects: 100% (8/8), done.
>  ! [remote rejected] dev -> dev (failed to unpack objects)

Considering that the final recap is unnecessary too.

> That leaves only the fact that the _specific_ reason the unpacker
> failed
> is not part of the usual status table. Fixing that is actually a little
> tricky because of the multiple processes involved (which do not already
> have a string-based communications channel between them).

So if the string could be passed back, rather than an "other" error code, the caller could format it into a nicer string.  Even with an existing error code field, you could still get rid of all uses of a single "other" code with unique numbers and have a separate string table that the caller can access.  Document those as "implementation specific, use the matching string table".

> And of course, it's still a bit cryptic to get "unresolved deltas after
> unpacking". However, that is one of those messages that _should_ never
> come up, unless the sender is pushing a bogus pack. I wouldn't be
> surprised if it an msysgit bug.
> 
> -Peff

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.