mailmap: clean up read_mailmap error handling
authorJeff King <peff@peff.net>
Wed, 12 Dec 2012 11:18:02 +0000 (06:18 -0500)
committerJunio C Hamano <gitster@pobox.com>
Wed, 12 Dec 2012 19:14:09 +0000 (11:14 -0800)
commit938a60d64fc91fd7d646ed33fad527b724d1e534
tree02ceb6fe318ea4a3b32e09c8ec7442f0a50670ef
parent086109006f695166daf2934417a20681b0c94ab8
mailmap: clean up read_mailmap error handling

The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.

This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:

  1. Return -1 on errors.

  2. Treat a missing entry (e.g., no mailmap.file given),
     ENOENT, or a non-existent blob (for mailmap.blob) as
     "no error".

  3. Complain loudly when a real error (e.g., a transient
     I/O error, no permission to open the mailmap file,
     missing or corrupted blob object, etc) occurs.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
mailmap.c