Re: Cherry-picking commits with empty messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Angus Hammond <angusgh@xxxxxxxxx> writes:

>>    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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]