Re: Cherry-picking commits with empty messages

[Angus Hammond <angusgh@gmail.com>]

>    But from the bigger UI consistency point of view, it would be
>    chaotic to change the default of some options for a single
>    command depending on the nature of the operand, so I would
>    recommend against going this route, and pick one view between
>    "give the user a chance to fix" or "the user must have done so on
>    purpose" and apply it consistently.
>
> 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.

Though I completely agree regarding having a consistent UI that
doesn't change it's behaviour based on the operand, I'd argue that
--allow-empty-message should default to true on cherry-pick for a
couple or reasons. Firstly, in the case that git perpetuates an empty
commit message that the user does not want, it is only damaging a
repository in a way that it is already damaged, clearly this still
isn't ideal, but it's certainly not as bad as damaging a repository
that's pristine. Arguably it's the user's responsibility to ensure
they don't TELL git to perpetuate their own bad commit.

Secondly, I'd don't like the idea of a command that 99.9% of the time
will run completely independently, but then every so often will become
interactive. This is probably a rare enough scenario that script
writers would reasonably assume that cherry-pick (without the
--allow-empty-message flag) is not an interactive command and write
their scripts accordingly. A user who made use of empty commit
messages would find any such scripts crashing on them or producing
strange results. Even if this is the fringe case, it seems to be a
substantially worse fringe case than that where we make a commit that
has no message at the user's instruction.

Thanks
Angus