commit: do not complain of empty messages from -C

When we pick another commit's message, we die() immediately if we find that it's empty and we are not going to run an editor (i.e., when running "-C" instead of "-c"). However, this check is redundant and harmful. It's redundant because we will already notice the empty message later, after we would have run the editor, and die there (just as we would for a regular, not "-C" case, where the user provided an empty message in the editor). It's harmful for a few reasons: 1. It does not respect --allow-empty-message. As a result, a "git rebase -i" cannot "pick" such a commit. So you cannot even go back in time to fix it with a "reword" or "edit" instruction. 2. It does not take into account other ways besides the editor to modify the message. For example, "git commit -C empty-commit -m foo" could take the author information from empty-commit, but add a message to it. There's more to do to make that work correctly (and right now we explicitly forbid "-C with -m"), but this removes one roadblock. 3. The existing check is not enough to prevent segfaults. We try to find the "\n\n" header/body boundary in the commit. If it is at the end of the string (i.e., no body), _or_ if we cannot find it at all (i.e., a truncated commit object), we consider the message empty. With "-C", that's OK; we die in either case. But with "-c", we continue on, and in the case of a truncated commit may end up dereferencing NULL+2. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>