Jeff King <p...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
