How to fill in an empty commit message?

This seems to be a bug which hasn't been fixed yet (although there are proposed patches for it). As a workaround, you can provide the message on the command line:

git commit --amend -m "foo"

If you need to edit your last commit (HEAD) message use git commit --amend -m 'new message'

$ git commit --allow-empty --allow-empty-message -m ''
[master 5db8236] 

$ git commit --amend
fatal: commit has empty message

$ git commit --allow-empty --amend -m 'new message'
[master d383d5c] new message

Keep in mind i'm using --allow-empty just to force git commit create an empty commit and --allow-empty-message to force git commit to create a commit with an empty message.

Starting git 2.0.1 (June 25, 2014), git won't complain anymore of an empty commit message when you rebase and attempt to put one.

See commit 076cbd6 by Jeff King (peff)

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.

---

Note: with Git 2.19, git rebase will use --allow-empty-message by default.
See "Rebasing a git history with empty commit messages".

---

Make sure to use Git 2.25 (Q1 2020) though: The sequencer machinery compared the HEAD and the state it is attempting to commit to decide if the result would be a no-op commit, even when amending a commit, which was incorrect, and has been corrected.

See commit 2d05ef2 (22 Nov 2019) by Phillip Wood (phillipwood).
^{(Merged by Junio C Hamano -- gitster -- in commit c920859, 05 Dec 2019)}

sequencer: fix empty commit check when amending

^{Signed-off-by: Phillip Wood}

This fixes a regression introduced in 356ee4659b ("sequencer: try to commit without forking 'git commit'", 2017-11-24, Git v2.17.0-rc0 -- merge listed in batch #2).
When amending a commit try_to_commit() was using the wrong parent when checking if the commit would be empty. When amending we need to check against HEAD^ not HEAD.

That series will mutate these tests to check that the advice includes suggesting rebase --skip to skip the fixup that would empty the commit.