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

Re: [PATCH v14 04/13] ref-filter: implement an `align` atom

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Aug 31, 2015, 18:02 UTC
Message-ID
<CAPig+cRig+zk=D1SDF7wBHuQgcQqb-4cHkmeVgLs5BaWzk9WRg@mail.gmail.com>
In-Reply-To
<vpqpp235pvg.fsf@anie.imag.fr>

On Mon, Aug 31, 2015 at 1:28 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 46 quoted lines
> Eric Sunshine <sunshine@sunshineco.com> writes:
>> On Mon, Aug 31, 2015 at 5:55 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
>>> On Sun, Aug 30, 2015 at 3:10 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>>> On Sun, Aug 30, 2015 at 9:38 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
>>>>> On Sun, Aug 30, 2015 at 8:57 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>>>>> On Sat, Aug 29, 2015 at 10:12 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
>>>>>>> +               } else if (!strcmp(name, "align"))
>>>>>>> +                       die(_("format: incomplete use of the `align` atom"));
>>>>>>
>>>>>> Why does %(align) get flagged as a malformation of %(align:), whereas
>>>>>> %(color) does not get flagged as a malformation of %(color:)? Why does
>>>>>> one deserve special treatment but not the other?
>>>>>
>>>>> Didn't see that, I think its needed to add a check for both like :
>>>>>
>>>>> else if (!strcmp(name, "align") || !strcmp(name, "color"))
>>>>>             die(_("format: improper usage of %s atom"), name);
>>>>>
>>>>> I had a look if any other atoms need a subvalue to operate, couldn't
>>>>> find any.
>>>>
>>>> Hmm, I'm not convinced that either %(align) or %(color) need to be
>>>> called out specially. What is the current behavior when these
>>>> "malformations" or any other misspelled atoms are used? Does it error
>>>> out? Does it simply ignore them and pass them through to the output
>>>> unmolested?
>>>
>>> It just simply ignores them currently, which is kinda bad, as the user
>>> is given no warning, and the atom is ineffective.
>>
>> Warning about unrecognized atoms may indeed be a good idea, however,
>> the current behavior isn't a huge problem since user discovers the
>> error when the output fails to match his expectation.
>
> It's a bit worse than it seems: without this change, using --format
> '%(align)%(end)' results in Git complaining about %(end) without
> matching atom, which is really confusing since you do have a %(align) (I
> got it for real while testing a preliminary version).
>
>> This behavior of ignoring unrecognized atoms predates your work,
>> doesn't it? If so, it's probably not something you need to address in
>> this series.
>
> I wouldn't insist in having it in the series, but now that it's here, I
> think we can keep it (if only to shorten the interdiff for the next
> iteration).

The unstated subtext in my original question is that the approach taken by this patch of warning only about unrecognized %(align) is too special-case; if it's going to warn at all, it should do so generically for any unrecognized %(atom). Special-casing the warning about malformed %(align) sets a poor precedent; it's code which will eventually need to be removed anyhow when the generic warning mechanism is eventually implemented.

Previous: Matthieu MoyNext: Karthik Nayak
Message 14 of 52 in “Port tag.c to use ref-filter.c”
  1. 00/13 Port tag.c to use ref-filter.cKarthik Nayak, Aug 29, 2015
  2. 01/13 ref-filter: move `struct atom_value` to ref-filter.cKarthik Nayak, Aug 29, 2015
  3. 02/13 ref-filter: introduce ref_formatting_state and ref_formatting_stackKarthik Nayak, Aug 29, 2015
  4. 03/13 utf8: add function to align a string into given strbufKarthik Nayak, Aug 29, 2015
  5. Torsten BögershausenAug 29, 2015
  6. Karthik NayakAug 29, 2015
  7. 04/13 ref-filter: implement an `align` atomKarthik Nayak, Aug 29, 2015
  8. Eric SunshineAug 30, 2015
  9. Karthik NayakAug 30, 2015
  10. Eric SunshineAug 30, 2015
  11. Karthik NayakAug 31, 2015
  12. Eric SunshineAug 31, 2015
  13. Matthieu MoyAug 31, 2015
  14. Eric SunshineAug 31, 2015
  15. Karthik NayakSep 1, 2015
  16. Matthieu MoySep 1, 2015
  17. Karthik NayakSep 1, 2015
  18. Karthik NayakAug 30, 2015
  19. Eric SunshineAug 30, 2015
  20. Karthik NayakAug 31, 2015
  21. Junio C HamanoAug 30, 2015
  22. Eric SunshineAug 30, 2015
  23. Karthik NayakAug 31, 2015
  24. Karthik NayakAug 31, 2015
  25. Matthieu MoyAug 31, 2015
  26. Karthik NayakAug 31, 2015
  27. 05/13 ref-filter: add option to filter out tags, branches and remotesKarthik Nayak, Aug 29, 2015
  28. Eric SunshineAug 30, 2015
  29. Karthik NayakAug 30, 2015
  30. Eric SunshineAug 30, 2015
  31. 06/13 ref-filter: introduce format_ref_array_item()Karthik Nayak, Aug 29, 2015
  32. Eric SunshineAug 30, 2015
  33. Karthik NayakAug 30, 2015
  34. Karthik NayakAug 30, 2015
  35. 07/13 ref-filter: add support for %(contents:lines=X)Karthik Nayak, Aug 29, 2015
  36. Eric SunshineAug 30, 2015
  37. Karthik NayakAug 30, 2015
  38. Eric SunshineAug 30, 2015
  39. Karthik NayakAug 30, 2015
  40. Eric SunshineAug 30, 2015
  41. Karthik NayakAug 31, 2015
  42. 08/13 ref-filter: add support to sort by versionKarthik Nayak, Aug 29, 2015
  43. 09/13 ref-filter: add option to match literal patternKarthik Nayak, Aug 29, 2015
  44. 10/13 tag.c: use 'ref-filter' data structuresKarthik Nayak, Aug 29, 2015
  45. 11/13 tag.c: use 'ref-filter' APIsKarthik Nayak, Aug 29, 2015
  46. 12/13 tag.c: implement '--format' optionKarthik Nayak, Aug 29, 2015
  47. 13/13 tag.c: implement '--merged' and '--no-merged' optionsKarthik Nayak, Aug 29, 2015
  48. Matthieu MoyAug 31, 2015
  49. Karthik NayakAug 31, 2015
  50. Matthieu MoyAug 31, 2015
  51. Karthik NayakAug 31, 2015
  52. Karthik NayakSep 1, 2015

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.