On Sun, Oct 06, 2013 at 12:48:56AM -0400, Jeff King wrote: > Instead of a segfault, let's print an error message and die > a little more gracefully. > [...] > --- > Not a huge deal, since we are terminating the program either way. There > are other places in the code with a bare parse_commit that could > probably use the same treatment. I didn't investigate them, but they > could easily build on the parse_commit_or_die here if somebody wants to > follow up.
Here are some follow-up patches that go on top. The first two are noop cleanups. The third and fourth are not strictly noops, but are minor behavior changes that should be strict improvements. There are a number of unchecked parse_commit calls whose fallout is more complicated. In many cases, we want to ignore an error (keeping in mind that parse_commit will already have printed a message to stderr) and keep going, in order to allow users to to get as much done as they can in a broken repository. The fifth patch deals with one of these cases. There are 8 more unchecked calls after this series, some of which may want to die(), or may want to be left alone; I didn't investigate deeply. There are also some cases where we do not die, but perhaps should. In general, I think it makes sense to let fetch-pack and rev-list work around broken history, but probably not things like blame, which would then provide subtly wrong answers. Still, I doubt it's a big deal in practice, since corrupted repositories are relatively rare (and the message to stderr does inform the user that something is wrong). [1/5]: assume parse_commit checks commit->object.parsed [2/5]: assume parse_commit checks for NULL commit [3/5]: use parse_commit_or_die instead of segfaulting [4/5]: use parse_commit_or_die instead of custom message [5/5]: checkout: do not die when leaving broken detached HEAD -Peff -- 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
