{"thread":{"id":"18974","subject":"Cryptic error messages?","startedAt":"2009-04-20T20:18:09Z","lastAt":"2009-04-22T22:07:35Z","messageCount":8,"participants":["John Dlugosz","Dmitry Potapov","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"111777","messageId":"450196A1AAAE4B42A00A8B27A59278E70ACE0030@EXCHANGE.trad.tradestation.com","threadId":"18974","inReplyTo":null,"subject":"Cryptic error messages?","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-04-20T20:18:09Z","receivedAt":"2009-04-20T20:18:09Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"$ git push\nCounting objects: 9, done.\nCompressing objects: 100% (8/8), done.\nWriting objects: 100% (8/8), 3.62 KiB, done.\nTotal 8 (delta 4), reused 0 (delta 0)\nUnpacking objects: 100% (8/8), done.\nfatal: unresolved deltas left after unpacking\nerror: unpack failed: unpacker exited with error code\nTo //tx01fs01/sys/dev/git/repositories/aardvark.git\n ! [remote rejected] dev -> dev (n/a (unpacker error))\nerror: failed to push some refs to\n'//tx01fs01/sys/dev/git/repositories/aardvark\n.git'\n\n\n\nHuh? I'm having trouble defending git's reputation.\n\nTradeStation 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.\n If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"111873","messageId":"20090421120814.GL25059@dpotapov.dyndns.org","threadId":"18974","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70ACE0030@EXCHANGE.trad.tradestation.com","subject":"Re: Cryptic error messages?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-04-21T12:08:14Z","receivedAt":"2009-04-21T12:08:14Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Apr 20, 2009 at 04:18:09PM -0400, John Dlugosz wrote:\n> $ git push\n> Counting objects: 9, done.\n> Compressing objects: 100% (8/8), done.\n> Writing objects: 100% (8/8), 3.62 KiB, done.\n> Total 8 (delta 4), reused 0 (delta 0)\n> Unpacking objects: 100% (8/8), done.\n> fatal: unresolved deltas left after unpacking\n\nI think that is the key message...\n\n> error: unpack failed: unpacker exited with error code\n> To //tx01fs01/sys/dev/git/repositories/aardvark.git\n> ! [remote rejected] dev -> dev (n/a (unpacker error))\n> error: failed to push some refs to\n> '//tx01fs01/sys/dev/git/repositories/aardvark\n> .git'\n> \n> \n> \n> Huh? I'm having trouble defending git's reputation.\n\nI don't think that information is very helpful. It would be far more\nuseful to know what version of Git on client and server sides are\nrunning. Also, running \"git fsck --full\" may be helpful.\n\nI suspect you have a very old Git version on the server side.\n\n\nDmitry\n"},{"id":"111883","messageId":"450196A1AAAE4B42A00A8B27A59278E70ACE0360@EXCHANGE.trad.tradestation.com","threadId":"18974","inReplyTo":"20090421120814.GL25059@dpotapov.dyndns.org","subject":"RE: Cryptic error messages?","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-04-21T16:54:38Z","receivedAt":"2009-04-21T16:54:38Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"It's git version 1.6.2.msysgit.0.186.gf7512. The remote is file based,\nso the same copy is being used. I would suspect that the problem is\nwith the network.\n\ngit fsck always tells me about dangling objects, so that's normal? In\nthis case, it said something about a broken link. I just recopied it\nfrom another location. But, is it possible to delete just the bad\nparts, and have a push from others flesh it out again?\n\n> -----Original Message-----\n> From: Dmitry Potapov [mailto:dpotapov@gmail.com]\n> Sent: Tuesday, April 21, 2009 7:08 AM\n> To: John Dlugosz\n> Cc: git@vger.kernel.org\n> Subject: Re: Cryptic error messages?\n> \n> On Mon, Apr 20, 2009 at 04:18:09PM -0400, John Dlugosz wrote:\n> > $ git push\n> > Counting objects: 9, done.\n> > Compressing objects: 100% (8/8), done.\n> > Writing objects: 100% (8/8), 3.62 KiB, done.\n> > Total 8 (delta 4), reused 0 (delta 0)\n> > Unpacking objects: 100% (8/8), done.\n> > fatal: unresolved deltas left after unpacking\n> \n> I think that is the key message...\n> \n> > error: unpack failed: unpacker exited with error code\n> > To //tx01fs01/sys/dev/git/repositories/aardvark.git\n> > ! [remote rejected] dev -> dev (n/a (unpacker error))\n> > error: failed to push some refs to\n> > '//tx01fs01/sys/dev/git/repositories/aardvark\n> > .git'\n> >\n> >\n> >\n> > Huh? I'm having trouble defending git's reputation.\n> \n> I don't think that information is very helpful. It would be far more\n> useful to know what version of Git on client and server sides are\n> running. Also, running \"git fsck --full\" may be helpful.\n> \n> I suspect you have a very old Git version on the server side.\n> \n> \n> Dmitry\n\nTradeStation 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.\n If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"112002","messageId":"20090422203251.GD14146@coredump.intra.peff.net","threadId":"18974","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70ACE0030@EXCHANGE.trad.tradestation.com","subject":"Re: Cryptic error messages?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-22T20:32:51Z","receivedAt":"2009-04-22T20:32:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 20, 2009 at 04:18:09PM -0400, John Dlugosz wrote:\n\n> $ git push\n> Counting objects: 9, done.\n> Compressing objects: 100% (8/8), done.\n> Writing objects: 100% (8/8), 3.62 KiB, done.\n> Total 8 (delta 4), reused 0 (delta 0)\n> Unpacking objects: 100% (8/8), done.\n> fatal: unresolved deltas left after unpacking\n> error: unpack failed: unpacker exited with error code\n> To //tx01fs01/sys/dev/git/repositories/aardvark.git\n> ! [remote rejected] dev -> dev (n/a (unpacker error))\n> error: failed to push some refs to\n> '//tx01fs01/sys/dev/git/repositories/aardvark\n> .git'\n> \n> Huh? I'm having trouble defending git's reputation.\n\nYeah, that is horribly cryptic. What is happening is:\n\n 1. send-pack on the local system spawns receive-pack on the\n remote, which in turn spawns unpack-objects as a helper\n\n 2. unpack-objects barfs with\n\n fatal: unresolved deltas left after unpacking\n\n to stderr which is the actual useful bit.\n\n 3. receive-pack notices that the unpacker failed, and spews\n\n error: unpack failed: unpacker exited with error code\n\n to stderr, in case unpack-objects didn't say anything.\n\n 4. receive-pack also marks the \"status\" passed back to send-pack\n as \"n/a (unpacker error)\"\n\n 5. send-pack gives you the usual nice status table with the ugly\n status from receive-pack marked in it, and then says \"OK, I failed\n to push\".\n\nSo making it better is not quite as simple as you might hope, since\nthere are three processes involved, and none knows that the other has\nspewed to stderr already. But I think there is some low-hanging fruit:\n\n 1. There is no point in receive-pack saying anything to stderr about\n the unpacker failing; in most cases, the unpacker already said\n something, and even if it didn't, we are reporting the problem to\n send-pack in the status field.\n\n 2. \"n/a (unpacker error)\" is unnecessarily cryptic. Yes, the specifics\n of the message are \"not available\" (which is presumably what the\n n/a stands for), but the user doesn't care. I think something like\n \"failed to unpack objects\" would be better.\n\nThat leaves only the fact that the _specific_ reason the unpacker failed\nis not part of the usual status table. Fixing that is actually a little\ntricky because of the multiple processes involved (which do not already\nhave a string-based communications channel between them).\n\nAnd of course, it's still a bit cryptic to get \"unresolved deltas after\nunpacking\". However, that is one of those messages that _should_ never\ncome up, unless the sender is pushing a bogus pack. I wouldn't be\nsurprised if it an msysgit bug.\n\n-Peff\n"},{"id":"112006","messageId":"20090422205006.GE14146@coredump.intra.peff.net","threadId":"18974","inReplyTo":"20090422203251.GD14146@coredump.intra.peff.net","subject":"Re: Cryptic error messages?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-22T20:50:07Z","receivedAt":"2009-04-22T20:50:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 22, 2009 at 04:32:51PM -0400, Jeff King wrote:\n\n> 3. receive-pack notices that the unpacker failed, and spews\n> \n> error: unpack failed: unpacker exited with error code\n> \n> to stderr, in case unpack-objects didn't say anything.\n\nActually, this is not true. receive-pack actually passes the error code\nback to send-pack, which prints it. I think it is doing so because we\nget that status separate from the individual ref status. But if you look\nat receive-pack, it doesn't even bother trying individual refs if the\nunpack failed; every ref will just get the \"unpack failed\" message.\n\n-Peff\n"},{"id":"112010","messageId":"7vws9c1jdz.fsf@gitster.siamese.dyndns.org","threadId":"18974","inReplyTo":"20090422205006.GE14146@coredump.intra.peff.net","subject":"Re: Cryptic error messages?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-22T21:14:00Z","receivedAt":"2009-04-22T21:14:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Apr 22, 2009 at 04:32:51PM -0400, Jeff King wrote:\n>\n>> 3. receive-pack notices that the unpacker failed, and spews\n>> \n>> error: unpack failed: unpacker exited with error code\n>> \n>> to stderr, in case unpack-objects didn't say anything.\n>\n> Actually, this is not true. receive-pack actually passes the error code\n> back to send-pack, which prints it. I think it is doing so because we\n> get that status separate from the individual ref status. But if you look\n> at receive-pack, it doesn't even bother trying individual refs if the\n> unpack failed; every ref will just get the \"unpack failed\" message.\n\nHow could it even \"bother\" to tell which ref? The protocol says \"Here are\nthe values for the refs after you unpack the data that follows; here is\nthe pack data for you\", and then you find the error in the pack data.\n"},{"id":"112014","messageId":"20090422212351.GB16096@coredump.intra.peff.net","threadId":"18974","inReplyTo":"7vws9c1jdz.fsf@gitster.siamese.dyndns.org","subject":"Re: Cryptic error messages?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-22T21:23:51Z","receivedAt":"2009-04-22T21:23:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 22, 2009 at 02:14:00PM -0700, Junio C Hamano wrote:\n\n> > Actually, this is not true. receive-pack actually passes the error code\n> > back to send-pack, which prints it. I think it is doing so because we\n> > get that status separate from the individual ref status. But if you look\n> > at receive-pack, it doesn't even bother trying individual refs if the\n> > unpack failed; every ref will just get the \"unpack failed\" message.\n> \n> How could it even \"bother\" to tell which ref? The protocol says \"Here are\n> the values for the refs after you unpack the data that follows; here is\n> the pack data for you\", and then you find the error in the pack data.\n\nSorry, I don't understand. The errors are coming from receive-pack, so\nit sends:\n\n unpack \\n\n ng refs/heads/whatever n/a (unpacker error)\\n\n\nSo what I mean is that receive-pack doesn't actually _do_ anything\nper-ref after the unpacker error. If there is an unpacker error, then it\n_always_ will say \"n/a (unpacker error)\".\n\nSo I wonder if it would be nicer for send-pack not to spew \"unpack\nerror: \" to stderr, and instead put something meaningful into\nthe status table, which is where people are expecting to find error\ncodes. Even if it is repetitious. IOW, something like:\n\n To git://blah/blah\n ! [remote rejected] foo -> foo (unpacker exited with error code)\n\nor if you are pushing several refs:\n\n To git://blah/blah\n ! [remote rejected] foo -> foo (unpacker exited with error code)\n ! [remote rejected] bar -> bar (unpacker exited with error code)\n\n-Peff\n"},{"id":"112022","messageId":"450196A1AAAE4B42A00A8B27A59278E70ACE0882@EXCHANGE.trad.tradestation.com","threadId":"18974","inReplyTo":"20090422203251.GD14146@coredump.intra.peff.net","subject":"RE: Cryptic error messages?","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-04-22T22:07:35Z","receivedAt":"2009-04-22T22:07:35Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"\n\n> Yeah, that is horribly cryptic. What is happening is:\n> ...\n\nThanks 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.\n\n> So making it better is not quite as simple as you might hope, since\n> there are three processes involved, and none knows that the other has\n> spewed to stderr already.\n\nI 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.\n\nWhat we are seeing here is an error log, not an exception.\n\n\n\n\n But I think there is some low-hanging fruit:\n> \n> 1. There is no point in receive-pack saying anything to stderr about\n> the unpacker failing; in most cases, the unpacker already said\n> something, and even if it didn't, we are reporting the problem to\n> send-pack in the status field.\n> \n> 2. \"n/a (unpacker error)\" is unnecessarily cryptic. Yes, the\n> specifics\n> of the message are \"not available\" (which is presumably what the\n> n/a stands for), but the user doesn't care. I think something like\n> \"failed to unpack objects\" would be better.\n\n\nSo you would wind up with something like:\n> $ git push\n> Counting objects: 9, done.\n> Compressing objects: 100% (8/8), done.\n> Writing objects: 100% (8/8), 3.62 KiB, done.\n> Total 8 (delta 4), reused 0 (delta 0)\n> Unpacking objects: 100% (8/8), done.\n> ! [remote rejected] dev -> dev (failed to unpack objects)\n\nConsidering that the final recap is unnecessary too.\n\n> That leaves only the fact that the _specific_ reason the unpacker\n> failed\n> is not part of the usual status table. Fixing that is actually a little\n> tricky because of the multiple processes involved (which do not already\n> have a string-based communications channel between them).\n\nSo 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\".\n\n> And of course, it's still a bit cryptic to get \"unresolved deltas after\n> unpacking\". However, that is one of those messages that _should_ never\n> come up, unless the sender is pushing a bogus pack. I wouldn't be\n> surprised if it an msysgit bug.\n> \n> -Peff\n\nTradeStation 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.\n"}]}