config: stop the config dump repeating section comments on keys

Innie::get_comment() answers "what documents this key", and falls back to
the section's comment for a key that has none of its own.  That is right
for a lookup and wrong for the dump, which writes section comments in
their own place: a key with no comment was handed its section's, so the
paragraph appeared twice, once above the [section] header and again above
the key, with the key reading as if the text described it.

    # Built-in domain; same 64-bit keys as bees v0.11.  function has no
    # default, so each [hash.NAME] sets its own: crc64, cityhash, ...

    [hash.crc64]

    # Built-in domain; same 64-bit keys as bees v0.11.  function has no
    # default, so each [hash.NAME] sets its own: crc64, cityhash, ...

    function = crc64

Skip a key comment that is the section comment already written.  Both the
key walk and the section walk climb the same default-section chain and
consult the same fallback layers, so equality is what "this key had
nothing of its own" looks like from here.

The key is left with the indent comment Innie::set() seeds it with, which
is what an uncommented key is supposed to look like on the way out.

hash.crc64.function is the only key either schema defines with a section
comment and no comment of its own, so it is the only line that changes in
--show-builtin-config for both versions.  This is the mirror image of the
masking case in test-innie-comment: there the fallback wrongly wins, here
it wrongly fires.

Assisted-by: Claude-Code:claude-opus-5

diff --git a/src/bees-config.cc b/src/bees-config.cc
index b9b1ca805fecad1464bfee80901b74bdf6b584ba..0faf6c6c6c33dd8b8428c675b999cc44dffcc128 100644 (file)
--- a/src/bees-config.cc
+++ b/src/bees-config.cc
@@ -441,8 +441,16 @@ bees_build_dump_innie(const Innie &merged, Innie &out)
                for (const auto &key : merged.keys(section)) {
                        const string sk = section + "." + key;
                        out.set(sk, merged.get(sk));
+                       // get_comment() answers "what documents this key", and falls
+                       // back to the section's comment for a key that has none of its
+                       // own.  That is the right answer for a lookup and the wrong one
+                       // here: this dump writes section comments in their own place,
+                       // just above, so taking the fallback would print the same
+                       // paragraph twice and leave the key sitting under a comment
+                       // that is not about it.  Both walks resolve the same way, so
+                       // equality is what "the key had nothing of its own" looks like.
                        const string comment = merged.get_comment(sk);
-                       if (!comment.empty()) {
+                       if (!comment.empty() && comment != section_comment) {
                                out.set_comment(sk, comment);
                        }
                }