Re: [PATCH v6 3/3] am: throw an error when passing --empty option without value

> Here is a place for you to explain why this change might be a good
> idea to defend it.  If we applied 1/3 and 2/3 but not this one, what
> happens?  "am --empty" (not "am --empty=<choice>") is accepted and
> behaves just like "am --empty=die"?  Is that a bad thing?
> 
> If it is unconditonally a bad thing, then this patch does not stand
> on its own.  It should be squashed into the previous step; otherwise
> it would be "oops, we didn't think it through and failed to detect
> an argument-less --error as an error in the previous step, and here
> is a fix for that mistake".  We try not to deliberately commit a
> mistake and then fix it to gain commit counts in this project (or
> putting it differently, we try to pretend we are better than we
> really are and did not make a mistake in the first place).
> 
> Or are you giving list participants and reviewers a choice between
> "'--empty' is a synonym to '--empty=die'" and "'--empty' alone is an
> error" because you cannot decide yourself?  If that is the case, you
> really really need to make it clear in this place between "From:"
> and "Signed-off-by:".  Why would we want to use this patch?  Why
> would we be better without this patch?
> 
> I haven't thought things through, but my gut feeling is that the
> semantics of the --empty=<choice> option is better _with_ this,
> in other words, it makes more sense to forbid "--empty" alone.  So
> if I were doing this series, I would probably have squashed this
> into the previous one, making it a two-patch series.
> 
> Thanks.