Git modification times & DDL blame

Bring Git timing and authorship into the overlay when the history is part of the answer.

Filesystem timestamps are not always the best historians. A fresh clone gives every file today's date; a checkout rewrites mtimes wholesale. Git knows better, so the overlay will read Git's own history for the DDL files it collects.

What Git adds

• A real modification time - when the definition last actually changed, not when your disk last touched the file.
• Authorship and message - git blame for a DDL object: who changed this table, when, and what the commit said they were doing.
• Branch context - which branch a local definition came from, so an overlay built from a feature branch says so.

The intended surface is the one you would guess: hover an object in the schema tree or the editor and see its history in the tooltip, next to its definition.

Why it is not the conflict rule

It is tempting to resolve file-versus-database conflicts by comparing timestamps. SQLly deliberately does not: the file wins and the database is kept as a shadow, whatever the dates say. Git times are for explaining the model - answering “how did this get like this?” - not for silently deciding which definition you meant.

Planned. It depends on the provenance the model already records - each file-sourced object carries its path, content hash, and byte span - which is the hook this work attaches to.