Re: [PATCH/RFC] doc: document error handling functions and conventions (Re: [PATCH 03/14] copy_fd: pass error message back through a strbuf)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Jeff King <peff@xxxxxxxx> writes:
>
>> On Fri, Dec 05, 2014 at 10:00:05AM -0800, Junio C Hamano wrote:
>>
>>> I am more worried about variable length part pushing the information
>>> that is given later out to the right, e.g. "error: missing file '%s'
>>> prevents us from doing X".  Chomping to [1024] is not a good
>>> strategy for that kind of message; abbreviating %s to /path/name/...
>>> (again, with literally "...") would be.

I have this one in my pile of Undecided topics:

    * jn/doc-api-errors (2014-12-04) 1 commit
     - doc: document error handling functions and conventions

     For discussion.
     What's the status of this one????

I think we all agree that the early part of the new documentation
text is good, but the last section that proposes to store more
detailed errors in caller supplied strbuf in textual form was
controversial (and I have not convinced myself it is a good idea
yet).

I could chuck the last section and then start merging the remainder
to 'next' to salvage the "obviously good bits".  Or do people want
to hash its last section a bit more?

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]