Re: Cherry-picking commits with empty messages

From: Angus Hammond <angusgh@gmail.com>
Date: Aug 2, 2012, 10:10 UTC
Message-ID: <CAOBOgRbH_ddjW+DJiVSYt5bADEgqf_E+L9offvnF8SdH+GR50g@mail.gmail.com>
In-Reply-To: <7vehnqdz9t.fsf@alter.siamese.dyndns.org>

On 1 August 2012 23:26, Junio C Hamano <gitster@pobox.com> 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.

Show 6 quoted lines

> 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.

Show 7 quoted lines

> 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.

Show 11 quoted lines

>> 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