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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 15, 2014, 00:16 UTC
Message-ID: <xmqqppmpfcx1.fsf@gitster.dls.corp.google.com>
In-Reply-To: <xmqqtxc1fdsk.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 12 quoted lines

> That is, you are saying with the above
>
>      if_exists = add_if_different AND ignore_if_same
>
> So you already have to support more than one actions depending on
> the condition, ...
> of conditions, I think.  Which is essentially the same as saying
> that you need this:
>
>>     action = do_Y_if_X_and_Z AND do_U_if_V
>
> Again, unless all the U's are limited to "ignore", that is.

Oh by the way, don't get me wrong. I am not saying that the last one is necessarily better or worse. I am only saying that the semantics proposed seems to be hard to explain and we need to do find a way to do better.

If you have these existing ones:

	Sob: A
        Sob: B
        Sob: C
        Sob: D

and you have "Sob: B" at hand, "Sob.if-missing" would not fire (because if-exists/if-missing is only about keys) ans "Sob.if-exists" will. What happens is now up to the action part (i.e. what follows "if_exists =", e.g. "add_if_different").

The conditional part of "add_if_different" action is explainable as a conditon on the value (as opposed to condition on keys, which is the left-hand-side). But what does a condition with "neighbour" in its name really mean? It is not a condition about the value, but also is a condition about the order of the existing records.

What is the right mental model the end-user needs to form when understanding these? Conditions on keys go on the left, and any other random conditions can come as a modifier after action e.g. add_if_same_value_is_not_at_the_end?