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

From: Junio C Hamano <[email-masked]>
Date: Fri, 05 Dec 2014 10:00:05 -0800

Jeff King <[email-masked]> writes:

> The only downside I can think of is that we may truncate the message in
> exceptional circumstances. But is it really any less helpful to say:
>
>   error: unable to open file: some-incredibly-long-filename-aaaaaa...
>
> than printing out an extra 100 lines of "a"? And I mean the "..."
> literally. I think mkerror() should indicate the truncation with a
> "...", just so that it is clear to the user. It should almost never
> happen, but when it does, it can be helpful to show the user that yes,
> we know we are truncating the message, and it is not that git truncated
> your filename during the operation.
>
> Is this truncation really a concern, and/or is there some other downside
> I'm not thinking of?

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.