git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 11, 2014, 18:07 UTC
Message-ID
<xmqqa9dxr09k.fsf@gitster.dls.corp.google.com>
In-Reply-To
<CAP8UFD1Nq-LkE=FW5dnBZKKd7-ORJPo1BFs3sY+MLGxuXEWuTw@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
Show 38 quoted lines
>> 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.
Show 10 quoted lines
>> 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.

Previous: Christian CouderNext: Christian Couder
Message 15 of 48 in “Add interpret-trailers builtin”
  1. 00/14 Add interpret-trailers builtinChristian Couder, Feb 6, 2014
  2. 01/14 Add data structures and basic functions for commit trailersChristian Couder, Feb 6, 2014
  3. Junio C HamanoFeb 6, 2014
  4. Christian CouderFeb 9, 2014
  5. Eric SunshineFeb 10, 2014
  6. Junio C HamanoFeb 6, 2014
  7. Christian CouderFeb 9, 2014
  8. 02/14 trailer: process trailers from file and argumentsChristian Couder, Feb 6, 2014
  9. Junio C HamanoFeb 7, 2014
  10. Christian CouderFeb 9, 2014
  11. Junio C HamanoFeb 10, 2014
  12. Christian CouderFeb 10, 2014
  13. Junio C HamanoFeb 10, 2014
  14. Christian CouderFeb 11, 2014
  15. Junio C HamanoFeb 11, 2014
  16. Christian CouderFeb 14, 2014
  17. Junio C HamanoFeb 14, 2014
  18. Christian CouderFeb 14, 2014
  19. Junio C HamanoFeb 14, 2014
  20. Junio C HamanoFeb 14, 2014
  21. Junio C HamanoFeb 15, 2014
  22. Junio C HamanoFeb 21, 2014
  23. Christian CouderFeb 23, 2014
  24. 03/14 trailer: read and process config informationChristian Couder, Feb 6, 2014
  25. 04/14 trailer: process command line trailer argumentsChristian Couder, Feb 6, 2014
  26. Junio C HamanoFeb 7, 2014
  27. Christian CouderFeb 9, 2014
  28. 05/14 trailer: parse trailers from input fileChristian Couder, Feb 6, 2014
  29. 06/14 trailer: put all the processing together and printChristian Couder, Feb 6, 2014
  30. 07/14 trailer: add interpret-trailers commandChristian Couder, Feb 6, 2014
  31. Junio C HamanoFeb 7, 2014
  32. Christian CouderFeb 7, 2014
  33. Junio C HamanoFeb 7, 2014
  34. Junio C HamanoFeb 7, 2014
  35. 08/14 trailer: add tests for "git interpret-trailers"Christian Couder, Feb 6, 2014
  36. Junio C HamanoFeb 7, 2014
  37. 09/14 trailer: if no input file is passed, read from stdinChristian Couder, Feb 6, 2014
  38. Junio C HamanoFeb 7, 2014
  39. 10/14 trailer: execute command from 'trailer.<name>.command'Christian Couder, Feb 6, 2014
  40. Junio C HamanoFeb 7, 2014
  41. Junio C HamanoFeb 7, 2014
  42. 11/14 trailer: add tests for trailer commandChristian Couder, Feb 6, 2014
  43. 12/14 trailer: set author and committer env variablesChristian Couder, Feb 6, 2014
  44. Junio C HamanoFeb 7, 2014
  45. Junio C HamanoFeb 7, 2014
  46. 13/14 trailer: add tests for commands using env variablesChristian Couder, Feb 6, 2014
  47. 14/14 Documentation: add documentation for 'git interpret-trailers'Christian Couder, Feb 6, 2014
  48. Eric SunshineFeb 10, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.