Junio C Hamano <gitster@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html