From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 05 Dec 2014 18:00:05 GMT
Subject: Re: [PATCH/RFC] doc: document error handling functions and conventions (Re: [PATCH 03/14] copy_fd: pass error message back through a strbuf)
Message-ID: <xmqqfvcuq8nu.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20141205000128.GA30048@peff.net>

Jeff King <peff@peff.net> 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.