Angus Hammond <angu...@gmail.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
