Skip to content

The rebase drill records a commit sha that changes on every run, so real evidence changes and timestamp noise look identical #292

Description

@pseudoseed

Established by builder pir-272 on 2026-08-31 while explaining a field in PR #291.

The field

codev/research/250-rebase-drill.json records contractRegeneration.source.commit. It is a throwaway merge commit that exists only inside the drill's scratch clone, written at rebase-drill.mjs:445-449:

git commit-tree <merged-tree-sha> -p <forkHead> -p <target> -m 'spec 250 drill: merged tree'

It is never pushed and is in neither real checkout. It exists because generate.mjs refuses any checkout whose HEAD is not pin.commit, so proving the contract still regenerates after a rebase needs a commit that did not exist before the rebase.

The problem

git commit-tree stamps author and committer time into the object, and the drill pins neither. So this sha changes on every drill run, even when both parents and the tree are byte-identical.

That means the recorded value is not an identifier of anything. Two runs of the same drill against the same inputs produce different evidence, and a reader comparing evidence across runs sees a change that carries no information.

It also means "regeneration output is byte-identical apart from the source hash" can never be quite true for this file, so a real change and a timestamp are spelled the same way in a diff. Anyone reviewing an evidence update has to know this field is noise, and nothing in the file says so.

What would close this

  • Pin GIT_AUTHOR_DATE and GIT_COMMITTER_DATE when writing the drill commit, so the sha is a function of its inputs and a change to it means an input changed.
  • Or stop recording the sha, and record what it is derived from: the two parent commits and the merged tree sha. Those are already stable.
  • Either way the field should say what it is. kind currently says "the three-way merge of the same two trees, written by git merge-tree", which is accurate about the object and silent about its stability.

Not a defect in PR #291

In that PR the sha moved for a real reason: one parent moved, 2f64a1b0ee2b to 26b4c2dc09f0, while the upstream target stayed at 9b2d04317c68. The builder measured both parents rather than inferring. This issue is about the field being unstable in general, which is what makes that check expensive to do by hand every time.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/coreCore libraries and shared logic

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions