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 10, 2014, 20:51 UTC
Message-ID
<xmqq38jqsnc2.fsf@gitster.dls.corp.google.com>
In-Reply-To
<20140210.205936.813126606054805390.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
Show 11 quoted lines
> Many entries with the same key but distinct values can be configured
> using:
>
> if_exists = add_if_different
> if_missing = add
>
> Many entries with the same key but values that can be the same can be
> configured using:
>
> if_exists = add
> if_missing = add

While the above certainly can express the combinations, I am still puzzled about the value of having "under this condition" (i.e. if-exists/if-missing) and "do this" (i.e. add/add-if-different) as two separate concepts.

If you do not have an existing entry with the same key, no new entry can be the same as an existing one---therefore, the former "allow only distinct values for the same key" can just say

  trailer."Fixes".action = add_if_different

or something, without any if_exists/if_missing. In a similar way, the latter "duplicated values allowed for the same key" can say

  trailer."Sob".action = add

You can throw into the mix other actions like "add_if_missing", you can also express "only one value allowed for the same key---the first one wins", "replace" to mean "replace if there is one with the same key", and "replace_or_add" to mean "same as 'replace', but add if there is no existing entries with the same key". Will we lose expressiveness by simplifying the semantics, getting rid of this "under this condition" part and instead making "do this" part more intelligent?

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 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.

What is the advantage of having such an extra axis? Does it make it easier to manage? Does it allow us to express more?

I can see that the location where a new entry (or a duplicated one) is added (i.e. do we prepend? do we append?) can be orthogonal to any of the above; no need to bring up 'where' in the discussion.

Previous: Christian CouderNext: Christian Couder
Message 13 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.