On Mon, Jul 21, 2014 at 3:43 AM, Samuel Bronson <naesten@xxxxxxxxx> wrote: > So, given that parse_object()'s documentation is: > > --8<---------------cut here---------------start------------->8--- > /* > * Returns the object, having parsed it to find out what it is. > * > * Returns NULL if the object is missing or corrupt. > */ > --8<---------------cut here---------------end--------------->8--- > > it probably should not call read_sha1_file() on a corrupt object. > > Options for fixing this would appear to include: > > 1. Saving the result of sha1_object_info(sha1, NULL) to a variable and > returning early if the object is corrupt. (But what happens if there > is corruption far enough in that it isn't seen when trying to grab > the object header?) > > 2. Calling read_object() and giving our own error messages. > > 3. Making read_sha1_file_extended only *optionally* die; since it's > calling die() directly. We've been using die() quite freely (or at least used to) and there are many more cases that can trigger die() and parse_object() can do nothing about it. Adding a "gentle" flag to read_sha1_file_extended and pass it further down could be the first step. Patches welcome. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html