Re: git-rebase -i prunes commits with empty commit-message

Michael Haggerty <mhagger@alum.mit.edu> writes:

Yes, I would say it is a bug in rebase-i if it refuses to deal with histories with such commits. Warning and giving the user a chance to add message _might_ be good, but allowing no way out would be inexcusable. Even adding a fake "(original commit had no message)" as the message and continuing would be better than stopping or dropping commits.

The Porcelain "git commit" by default complains if you do not give any message, because it usually is an end-user mistake to directly use "git commit" and not writing anything about the resulting commit. However,

 (1) The plumbing allows it because such a policy to forbid commits
     without comments does not belong there, e.g. this would succeed:

     $ git commit-tree HEAD^{tree} </dev/null

 (2) Even the Porcelain allows it if you ask nicely:

     $ git commit --cleanup=verbatim -m ''

These are primarily so that you can deal with histories created by other people's tools (e.g. foreign SCM, third party Porcelains, etc.). You do not have much control over histories created by them, and our commit creating commands need to be usable as an ingredient for you to write conversion tools (like filter-branch or rebase-i).