Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> Does git really claim to handle commits with empty commit messages?
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).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html