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

> 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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to