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 messages. 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. Cheers, Chris. -- 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
