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

Re: [PATCH v2 0/6] usage API: Add and use die_message()

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Dec 24, 2021, 17:01 UTC
Message-ID
<211224.86r1a2gcg0.gmgdl@evledraar.gmail.com>
In-Reply-To
<20211222185715.1090524-1-jonathantanmy@google.com>
On Wed, Dec 22 2021, Jonathan Tan wrote:
Show 15 quoted lines
>> A small set of fixes to usage.[ch]'s API use that will go towards
>> enabling nicer things down the road. See [1] for the v1 summary
>> 
>> I believe this should address all the feedback Junio had on the
>> v1.
>> 
>> Aside from the substantially rewritten 6/6 and much simplified 4/6 the
>> end-state is almost the same, but things are better split up,
>> explained etc. now.
>> 
>> 1. https://lore.kernel.org/git/cover-0.4-00000000000-20211206T165221Z-avarab@gmail.com/
>
> I haven't looked at this round of patches yet, but for the convenience
> of reviewers, it would have been great if you linked to a prior
> discussion [1],

FWIW this is (indirectly) linked-to upthread. I linked to this RFC series which this is peeled from: https://lore.kernel.org/git/RFC-cover-00.21-00000000000-20211115T220831Z-avarab@gmail.com/

Which in turn links to the earlier series you commented on that die_message() is peeled off from: https://lore.kernel.org/git/cover-v3-0.6-00000000000-20211022T175227Z-avarab@gmail.com/

> including an email from me with comments that (as far as
> I know) haven't been addressed [2].

Is there anything to address in the context of this current series? I.e. you're commenting on leak detection, which isn't at all the goal of this series.

I.e. I had these die_message() changes that I worked into that series, but there didn't seem to be any interest in code changes that "solved" issues of SANITIZE=leak interaction with various non-CI compiler versions/flags, so I didn't think it was worth pursuing.

But as this series shows die_message() is also something we can use in other contexts.

> [1] https://lore.kernel.org/git/patch-1.1-5a47bf2e9c9-20211021T114223Z-avarab@gmail.com/
> [2] https://lore.kernel.org/git/20211027215053.2257548-1-jonathantanmy@google.com/
Previous: Junio C Hamano
Message 22 of 22 in “usage API: Add and use die_message()”
  1. 0/4 usage API: Add and use die_message()Ævar Arnfjörð Bjarmason, Dec 6, 2021
  2. 2/4 usage.c API users: use die_message() where appropriateÆvar Arnfjörð Bjarmason, Dec 6, 2021
  3. Junio C HamanoDec 6, 2021
  4. 1/4 usage.c: add a die_message() routineÆvar Arnfjörð Bjarmason, Dec 6, 2021
  5. Junio C HamanoDec 6, 2021
  6. Junio C HamanoDec 6, 2021
  7. 4/4 config API: don't use vreportf(), make it static in usage.cÆvar Arnfjörð Bjarmason, Dec 6, 2021
  8. Junio C HamanoDec 6, 2021
  9. Ævar Arnfjörð BjarmasonDec 7, 2021
  10. 3/4 usage.c + gc: add and use a die_message_errno()Ævar Arnfjörð Bjarmason, Dec 6, 2021
  11. Junio C HamanoDec 6, 2021
  12. 0/6 usage API: Add and use die_message()Ævar Arnfjörð Bjarmason, Dec 7, 2021
  13. 1/6 usage.c: add a die_message() routineÆvar Arnfjörð Bjarmason, Dec 7, 2021
  14. 2/6 usage.c API users: use die_message() for "fatal :" + exit 128Ævar Arnfjörð Bjarmason, Dec 7, 2021
  15. 3/6 usage.c API users: use die_message() for error() + exit 128Ævar Arnfjörð Bjarmason, Dec 7, 2021
  16. 4/6 gc: return from cmd_gc(), don't call exit()Ævar Arnfjörð Bjarmason, Dec 7, 2021
  17. 5/6 usage.c + gc: add and use a die_message_errno()Ævar Arnfjörð Bjarmason, Dec 7, 2021
  18. 6/6 config API: use get_error_routine(), not vreportf()Ævar Arnfjörð Bjarmason, Dec 7, 2021
  19. Junio C HamanoDec 7, 2021
  20. Jonathan TanDec 22, 2021
  21. Junio C HamanoDec 22, 2021
  22. Ævar Arnfjörð BjarmasonDec 24, 2021

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.