[PATCH 0/5] parse_commit cleanups

[Jeff King <peff@peff.net>]

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