[modderation]

> a table of commits-modifying-this-thing [...] a linear list of commits doesn't convey branch/merge topology well.

Agreed. Presenting both the local diff and the location in the commit graph seems like a better bet for helping people glean understanding of a change's purpose and context. I'm also thinking of using a table of per-item changes that's tied to the commit graph for topologically sorted history and reachability information. This will probably be backed by a per-commit list of item identifiers with their hashed content for easier comparison.

It sounds like your abstraction is doing a great job of representing file structure. For the most part, I'm just looking at telling users that they should look at a set of related symbols and revisions after an identifier's body has changed. The user is then responsible for performing a review and updating the "last-approved" information.

As a more concrete example, I'm expecting users to maintain their own mappings to items in the upstream sources:

  #[rawr(
      codebase = "reality",
      kind = "constant",
      identifier = "f_pi",
      path = "src/constants.h",
      revision = "123abc456",
      notes = "This probably shouldn't change, but it would be good to know if \
      the upstream team makes non-Euclidean alterations to the simulator."
  )]
  const PI: f64 = 3.14159;

If f_pi's contents have changed since revision 123, the new value can be flagged for review. In the example case, upstream's f_pi was changed to a new value. The user should be informed that PI was updated in Reality's src/constants.h@1897246. They can review the upstream change, reimplement it in the downstream codebase, and update the metadata to reflect the coordinates of the last change.

  #[rawr(
      codebase = "reality",
      kind = "constant",
      identifier = "f_pi",
      path = "src/constants.h",
      revision = "1897246",
      notes = "Required by Legal Counsel for compliance with bill #246."
  )]
  const PI: f64 = 3.2;

I'm starting to think that the best way to present the changelist is to spit out deep links into an Asqi instance. By the sounds of it, you've also got all the necessary data in the self-hosted Asqi container's /db volume. If you don't mind, I'd like to see if I can directly consume that instead of building my own Tree-Sitter integration.

(Personally, I wouldn't want to hear that my non-free product was being implemented by someone's pet project :) Thankfully, I think we're heading in different directions, leveraging and presenting the same dataset in very different ways. In this case, I'm actually thrilled that someone else is implementing the machinery required by my pet project. Now I'm closer to exploring and following the fast-moving codebases that I wanted to reimplement in the first place!)