• Jeff King's avatar
    react to errors in xdi_diff · 3efb9880
    Jeff King authored
    When we call into xdiff to perform a diff, we generally lose
    the return code completely. Typically by ignoring the return
    of our xdi_diff wrapper, but sometimes we even propagate
    that return value up and then ignore it later.  This can
    lead to us silently producing incorrect diffs (e.g., "git
    log" might produce no output at all, not even a diff header,
    for a content-level diff).
    In practice this does not happen very often, because the
    typical reason for xdiff to report failure is that it
    malloc() failed (it uses straight malloc, and not our
    xmalloc wrapper).  But it could also happen when xdiff
    triggers one our callbacks, which returns an error (e.g.,
    outf() in builtin/rerere.c tries to report a write failure
    in this way). And the next patch also plans to add more
    failure modes.
    Let's notice an error return from xdiff and react
    appropriately. In most of the diff.c code, we can simply
    die(), which matches the surrounding code (e.g., that is
    what we do if we fail to load a file for diffing in the
    first place). This is not that elegant, but we are probably
    better off dying to let the user know there was a problem,
    rather than simply generating bogus output.
    We could also just die() directly in xdi_diff, but the
    callers typically have a bit more context, and can provide a
    better message (and if we do later decide to pass errors up,
    we're one step closer to doing so).
    There is one interesting case, which is in diff_grep(). Here
    if we cannot generate the diff, there is nothing to match,
    and we silently return "no hits". This is actually what the
    existing code does already, but we make it a little more
    Signed-off-by: default avatarJeff King <peff@peff.net>
    Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
diffcore-pickaxe.c 5.74 KB