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

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

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

Show 6 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
> 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?

Having said all that, it appears that nobody seems to be able to come up with a saner arrangement that would not paint us into a tough corner that we would not be able to later escape from without being backward incompatible---I certainly didn't.

So... let's take this from your earlier message:

>> If we limit it to "if_exists" and "if_missing", the user can remember
>> that without things becoming too complex.

and go with the semantics the posted patches (I believe I have the latest from you on 'pu') attempt to implement, at least for now.

IOW, when re-rolling, let's not try changing the arrangement to use if-exists/if-missing (configuration variable names) for keys' existence and include chosen set of conditions on values as modifiers to the action (i.e. X in "do_Y_in_X").