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

Re: [PATCH 2/2] fsck: document msg-id

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 24, 2022, 17:33 UTC
Message-ID
<xmqq8rl5t9ca.fsf@gitster.g>
In-Reply-To
<3aec3d2c9ca65a37a367c3a7c9081bbd4cd44ae0.1666623639.git.gitgitgadget@gmail.com>
"John Cai via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 6 quoted lines
> From: John Cai <johncai86@gmail.com>
>
> The git-config documentation lacks mention of specific <msg-id> that
> are supported. While git-help --config will display a list of these options,
> often developers' first instinct is to consult the git docs to find valid
> config values.

Good observation. "help --config" only gives names and no description, so maintaining the description like this new file does make sense.

Can you also add a referencing comment to fsck.h to tell that folks who add a new error type that they need to update the -msgids.txt file as well?

Does this list in the new file cover all existing messages, by the way?

I also wonder if the order of the entries in this file should be alphabetical, unlike the entries in fsck.h where more severe ones come earlier than the less severe ones. In a sense, matching the order of two lists makes it easier to maintain, and grouping by severity in the doc might or might not find it easier to scan and find what they are, but one of the biggest reason why users will come to this list is when they see a particular error message and want to understand what that means, no? At that point it would be easier to look things up if

 (1) the list contains EVERYTHING, even the ones that you are not
     supposed to configure away.
 (2) the list is sorted alphabetically, regardless of the severity.

The first point suggests that it may be a mistake to have the main list appear in the "what configuration knobs are available for squelching fsck error messages". It is OK to refer from there to the main list, but the main list should list everything, with comments like "(this error cannot be configured away)", no?

In other words, I think it is better to have a master list of everything, with their message ID and textual description, which essentially is your fsck-msgids.txt but additionally mention which ones are by default FATAL and cannot be configured away (even better, we can mention what severity level each of them is by default, by mirroring that is in fsck.h).

And that master list should NOT be made a part of fsck.<msg-type> configuration item, like this patch did. It should be a separate section in "git fsck --help" output whose section title is "Fsck errors" or something.

Then the existing description of fsck.<msg-type> configuration can refer to that "Fsck errors" section for what msg types exist.

Another thing that I noticed while thinking about the patch, but is better left outside the scope of this patch, is that an attempt to configure fatal ones away is prevented by fsck.c::fsck_set_msg_type() but "git help config | grep '^fsck\.'" lists them. I think the "help config" should be fixed.

I almost suggested to extend the FOREACH_FSCK_MSG_ID() definition in fsck.h so that fsck-msgids.txt gets auto-generated (what is missing in fsck.h that prevents us from doing so is the textual explanation you added in the new file in your patch---they could come from comments on the same line, for example, and can be extracted via a Perl or sed script at build time). I do not know if it is a good idea, especially if we forsee a future in which we may be translating the documentation, so decided against making such a suggestion.

But at least, we could _lint_ the manually curated fsck-msgids.txt using what is in fsck.h to see if a new MSG_ID added to fsck.h is missing from the doc, or a MSG_ID whose default severity is updated in fsck.h is stale in the doc, etc. That can be left for the future updates, but we should at least instruct developers to keep them in sync in fsck.h by adding a comment.

Thanks.
Previous: John Cai via GitGitGadgetNext: Ævar Arnfjörð Bjarmason
Message 3 of 35 in “Document fsck msg ids”
  1. 0/2 Document fsck msg idsJohn Cai via GitGitGadget, Oct 24, 2022
  2. 2/2 fsck: document msg-idJohn Cai via GitGitGadget, Oct 24, 2022
  3. Junio C HamanoOct 24, 2022
  4. Ævar Arnfjörð BjarmasonOct 25, 2022
  5. Junio C HamanoOct 25, 2022
  6. 1/2 fsck: remove the unused BAD_TAG_OBJECTJohn Cai via GitGitGadget, Oct 24, 2022
  7. Junio C HamanoOct 24, 2022
  8. Junio C HamanoOct 24, 2022
  9. John CaiOct 24, 2022
  10. Jeff KingOct 24, 2022
  11. Junio C HamanoOct 24, 2022
  12. 0/2 Document fsck msg idsJohn Cai via GitGitGadget, Oct 25, 2022
  13. 1/2 fsck: remove the unused BAD_TAG_OBJECTJohn Cai via GitGitGadget, Oct 25, 2022
  14. 2/2 fsck: document msg-idJohn Cai via GitGitGadget, Oct 25, 2022
  15. Junio C HamanoOct 25, 2022
  16. Junio C HamanoOct 25, 2022
  17. Documentation: add lint-fsck-msgidsJunio C Hamano, Oct 25, 2022
  18. 0/4 document fsck error message idsJunio C Hamano, Oct 25, 2022
  19. 1/4 fsck: remove the unused BAD_TAG_OBJECTJunio C Hamano, Oct 25, 2022
  20. 2/4 fsck: remove the unused MISSING_TREE_OBJECTJunio C Hamano, Oct 25, 2022
  21. 3/4 fsck: document msg-idJunio C Hamano, Oct 25, 2022
  22. 4/4 Documentation: add lint-fsck-msgidsJunio C Hamano, Oct 25, 2022
  23. Ævar Arnfjörð BjarmasonOct 26, 2022
  24. Jeff KingOct 26, 2022
  25. Junio C HamanoOct 26, 2022
  26. Ævar Arnfjörð BjarmasonOct 26, 2022
  27. Jeff KingOct 28, 2022
  28. Ævar Arnfjörð BjarmasonOct 28, 2022
  29. Jeff KingOct 28, 2022
  30. Ævar Arnfjörð BjarmasonOct 28, 2022
  31. John CaiOct 28, 2022
  32. Ævar Arnfjörð BjarmasonOct 28, 2022
  33. Junio C HamanoOct 28, 2022
  34. Jeff KingOct 28, 2022
  35. Jeff KingOct 28, 2022

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.