Re: [PATCH 3/4] add: introduce '--resolved' option

Junio C Hamano <[email protected]> writes:

>> I wonder if we should simply write 'addremove', as this part of the
>> change is about rewriting the open-coded die_for_incompatible_opt2()
>> in the original and using die_for_incompatible_opt3() to add a third
>> option.
>
> Not really.  I forgot that addremove is futzed before this part when
> add_resolved is present, so using addremove would mean both
> addremove and add_resolved are on, mistakenly complaining about -A
> that the user never gave us.
>
> So "0 < addremove_explicit" that is.

Well, this episode illustrates that the option parsing in "git add"
is unnecessarily confusing, and I think the reason is because it
conflates the presence of each command line option and the behaviour
the program wants to exhibit into the same variable.  addremove for
example is about "removals are also recorded in the index", and that
becomes effective primarily when "-A" option is given, but "-A" is
not the only thing to turn it on.

Perhaps revamping the way the options are parsed so that the
incompatible options are noticed upfront, and then deciding the
behaviour based on the primary operating mode that was parsed by the
ooption parser in a separate step might make things less confusing?