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

Jeff King [off-list ref] 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.