// the find
AmrDeveloper/GQL
GitQL is a extensible SQL-like query language and SDK to perform queries on various data sources such .git files with supports of most of SQL features such as grouping, ordering and aggregation and window functions and allow customization like user-defined types and functions
GitQL lets you run SQL queries against local git history — commits, branches, tags, diffs — treating your `.git` directory as a database. The more interesting part is the SDK underneath it: a full in-memory query engine you can wire to any data source, which has already spawned tools for querying LLVM IR, C/C++ source, and file systems.
The SDK architecture is genuinely well-structured — clean crate separation between AST, parser, engine, stdlib, and CLI means you can embed just the query engine without dragging in git dependencies. SQL feature coverage is deeper than you'd expect: window functions, QUALIFY, array slicing, interval arithmetic, and user-defined types all work. The `diffs_changes` table with per-path insertion/removal counts is actually useful for real questions like 'which files churn most'. Typo-tolerant error messages via name similarity hints are a nice quality-of-life detail most toy query languages skip.
Everything runs in memory, so querying a large repo with a broad `SELECT * FROM commits` will load the full history before filtering — there's no predicate pushdown to libgit2. The SDK's extensibility story requires writing Rust; there's no scripting layer or FFI bindings, so 'build your own QL tool' means committing to a Rust crate. With 96 forks against 3,500 stars, the SDK hasn't attracted the third-party ecosystem the README implies it's aiming for. The git data model is also fairly shallow — no support for worktree state, stashes, or the reflog.