Like many of you, I exported my tree from MyHeritage as GEDCOM and wanted to move it between programs without losing names, notes or dates. The validators I tried either drowned me in noise (516 identical vendor-tag messages hid real errors behind a 200-item cap) or simply couldn’t see structural damage — a CONT nested under a CONC is legal line by line and broken as a whole. So I built the linter I wanted to have before importing: gedlint, open source, in Rust.
What it does: reads a GEDCOM (5.5.1 and 7.0), finds structural, encoding, referential and semantic problems, explains each one in plain language, and safely repairs some of them (always with a backup). It runs three ways: a CLI (cargo install gedlint), a GitHub Action, and a browser viewer that cannot upload your file — it’s compiled to WebAssembly and blocked from the network by design.
It runs clean on the official FamilySearch 7.0 sample files with zero false positives, so the findings it does report on real exports are worth reading. On my own 544-person tree it found 1,014 issues, including 140 of that structural CONT-under-CONC breakage that no validator I tried could see.
What I’d love from Gramps users: run your GEDCOM through the viewer (nothing is uploaded, no install) and tell me what it found — rule codes and counts, please, never your data. If Gramps’ own export trips rules that look like false positives for Gramps-style data, that’s exactly the feedback that hardens the rules. One rule group you may care about: an opt-in hispanic-naming ruleset (surname commas, married names in _MARNM, abbreviated given names) — conventions, not spec violations, off by default. If your region or tradition has naming/placement conventions gedlint should know about, describe them and they could become the next ruleset.