Re: Cherry-picking commits with empty messages

Angus Hammond [off-list ref] writes:

quoted

   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.

I've read your entire response three times, and I am having a hard
time deciding if you are against my suggestion, or you misread my
suggestion.

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.

I guess by "perpetuates" you meant there was already a commit with
an empty message, by "the user does not want" you consider such a
commit is a bad thing, and by "to ensure they don't TELL git", you
meant it is the user's responsibility not to give an extra option to
cause Git to replay a bad (= having an empty message) commit and
leave it in the resulting history.

It sounds to me that you are advocating for "git cherry-pick"
without any flags to stop and do not commit when given a commit with
an empty message.

And that is what I thought I was suggesting.  Give users a support
to say "git cherry-pick --allow-empty", but do not by default enable
it.  Perhaps I sounded as if I was suggesting the opposite?

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.

As "cherry-pick" is expected to stop and give control back whenever
there is conflicts, this does not apply.  Any script that uses
cherry-pick to replay an existing commit has to be prepared to see
it stop and give control back to the script already, or the script
is unusable.  Note that the script would not be buggy even if the
only thing it does when it sees cherry-pick stop and give control to
it is to abort and give control back to the user.