Re: Cherry-picking commits with empty messages

From: Chris Webb <chris@arachsys.com>
Date: Aug 2, 2012, 08:55 UTC
Message-ID: <20120802085554.GI19416@arachsys.com>
In-Reply-To: <7vd33afqjh.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@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.