Re: Cherry-picking commits with empty messages

On 1 August 2012 23:26, Junio C Hamano [off-list ref] wrote:

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.

My apologies, I can see how my message wasn't as clear as it could have been.

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.

I was just trying to say that cherry-pick will only ever create a
blank commit message where one already exists in the repository, so
git shouldn't worry about copying that blank commit message,
especially since the user has explicitly told git (by running
cherry-pick) that they want those commits copied.

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?

I meant the opposite, that without any flags it should just copy the
blank commit silently.

quoted

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.

Fair enough, I don't make heavy use of cherry-pick, so that didn't occur to me.

Since you've pointed out that the scripting argument is invalid, I'm
now inclined to support what you originally proposed (by default
refuse to create an empty commit message, offer a flag to override
that default), but just wanted to clear up my original point since it
wasn't written very clearly.

Thanks
Angus