Junio C Hamano <gits...@pobox.com> writes:
> My recommendation, backed by the above line of thought, is to add
> support for the "--allow-empty-message" option to both "rebase [-i]"
> and "cherry-pick", defaulting to false.
Thanks for the very detailed analysis and advice Junio. I like your
suggested --allow-empty-message option for cherry-pick because it's
consistent with the same option in standard commit, and doesn't change the
behaviour for existing users who might rely on cherry-pick catching blank
With rebase -i, the fix might be slightly more involved than just passing
through --allow-empty-message (if given) to cherry-pick, especially given
that sometimes we git cherry-pick -n && git commit --allow-empty-message,
and at other times we do standard git cherry-pick which refuses to pick a
commit without a message.
Given a history with empty commits, as a general principle it feels like it
should be possible to edit or reword those commits to make them non-empty
without giving --allow-empty-message, but that to generate new history
containing empty messages, --allow-empty-message should be required, whether
to commit [--amend] during rebase, or to the rebase -i command itself.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html