From: Chris Webb <chris@arachsys.com>
Date: Thu, 02 Aug 2012 08:55:59 GMT
Subject: Re: Cherry-picking commits with empty messages
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.