> 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.��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m