> 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. 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. 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. This is probably a rare enough scenario that script writers would reasonably assume that cherry-pick (without the --allow-empty-message flag) is not an interactive command and write their scripts accordingly. A user who made use of empty commit messages would find any such scripts crashing on them or producing strange results. Even if this is the fringe case, it seems to be a substantially worse fringe case than that where we make a commit that has no message at the user's instruction. Thanks Angus -- 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