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 <gitster@pobox.com>
Date: Dec 5, 2014, 18:00 UTC
Message-ID: <xmqqfvcuq8nu.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20141205000128.GA30048@peff.net>

Jeff King <peff@peff.net> writes:

Show 14 quoted lines

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