Re: [PATCH v5 02/14] trailer: process trailers from file and arguments

[Junio C Hamano <gitster@pobox.com>]

Christian Couder <christian.couder@gmail.com> writes:

>> Even if we assume, for the sake of discussion, that it *is* a good
>> idea to separate "under this condition" part and "do this" part, I
>> do not think the above is the only or the best way to express
>> "distinct values allowed for the same key".  How do we argue that
>> this from your example
>>
>>   if_exists = add_if_different
>>   if_missing = add
>>
>> is a better design than this, for example?
>>
>>   if_key_value_exists = ignore ; exact matching <key,val> exists
>>   if_key_exists = add          ; otherwise
>>   if_missing = add
>
> The question is what happens if we want to say "if the same <key,
> value> pair exists but not near where we would add.
>
> With the solution I implemented, that is:
> ...
> With the solution you suggest, should we have:
> ...
>   if_key_value_exists_not_neighbor = add ; exact matching <key,val>
> ...
> or:
>   if_key_value_exists = ignore_if_neighbor ; exact matching <key,val> exists
> ...
>
> And what happens if we want to say "if key exists and value matches
> <regex>", how do we express that then?
> Or what happens when we want to say "if key exists and <command> succeeds"?
> ...
> With what I suggest, we can still say:
> ...
> And then people might ask if they can also use something like this:
> ...
> and it will look like we are trying too much to do what should be done
> in only one script.

I think the above illustrates my point very clearly.

These numerous questions you have to ask are indications why
choosing "this condition goes to the left hand side of the equal
sign (e.g. exists)" and "this condition goes to the right hand side
(e.g. do-this-if_neighbor)" is not working well.  The user has to
remember which conditions go to the variable name and which
conditions go to the action part.

And the made-up alternative you listed above is not a solution I
suggest to begin with---it is a strawman "if we assume such a
splitting were a good idea" in the first place ;-).

What I was wondering if it is an better alternative was the below.

>> The latter splits remaining conditional logic from "do this" part
>> (no more "add_if_different" that causes "add" action to see if there
>> is the same key and act differently) and moves it to "under this
>> condition" part.
>> ...
>> I am trying to illustrate that the line to split the "under this
>> condition" and "do this" looks arbitrary and fuzzy here, and because
>> of this arbitrary-ness and fuzziness, it is not very obvious to me
>> why it is a good idea to have "under this condition" as a separate
>> concept from "do this" settings.

That is, not splitting the logic into two parts like you did,
i.e. "if_X = do_Y_if_Z", which invites "why is it not if_true =
do_Y_if_X_and_Z, if_X_and_Z = do_Y, if_Z = do_Y_if_X"?

One possible way to avoid the confusion is to say "do_Y_if_X_and_Z"
without making the rule split into conditions and actions---I am
NOT saying that is _better_, there may be other solutions to avoid
this two-part logic in a cleaner way.