> 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. Hamano, I could not make this decision like what you said between "'--empty' is a synonym to '--empty=die'" and "'--empty' alone is an error". In my opinion, it is a little wired that '--empty' should not act as "died" semantically. Reversely, it may be better to support a synonym between '--quiet' and '--empty=skip'. I will squash the commit into the previous one later and hope all participants and reviewers make a decision.
