[#2079] Add commits table (and decide how to store parents)

[alanpeixinho]

Parent

#2079

checkouts is a CI submission, not a git object. Author, committer, subject, and parents belong on a commit row keyed by hash. Same hash can appear on many checkouts.

This issue is schema only (Django models + migration). No git fetch and no job to fill the tables.

commits

Column	Notes
id	Big serial, PK (cheap FKs later)
git_commit_hash	text, unique, not null
author_name, author_email, author_date	nullable (timestamptz for date)
committer_name, committer_email, committer_date	nullable
subject	first line of the message, nullable
message	full message, nullable
fetched_from_url	repo used when metadata was filled, nullable

Stubs: a parent hash may have no metadata yet. If we FK to commits.id, insert a row with only git_commit_hash until a later job fills it.

Do not add these columns onto checkouts.

Decision: how to store parents

Pick one in this PR and document it. Both are in scope for A; do not ship both.

Option 1 — commit_parents table

Column	Notes
commit_id	FK → commits.id (child)
parent_id	FK → commits.id (parent)
ord	smallint; 0 = first parent

Unique (commit_id, ord).

• First-parent walk and merge check (ord > 0 / count > 1) are normal joins
• Integrity: parent must exist (stubs)
• Ingestion is heavier: upsert stubs, then edges

Option 2 — array on commits

e.g. parent_hashes text[] (index 0 / Postgres [1] = first parent).

• Simpler writes: one upsert, no stubs
• No FK to parent rows; hashes can exist before commits has them
• Walks/filters on parents are clumsier than a join

Lean Option 1 if we already want surrogate id for later FKs and first-parent “next commit”. Lean Option 2 if we want the smallest migration and the job to stay dumb.

Same DB as Checkouts. Follow existing db_table / index naming.