Remember: bow out gracefully

you're arguing a position which indicates you don't know git's physical (textual) commmit structure.

Spend some quality time with:

    git cat-file -p HEAD

You'll get something like:

    tree ff1234...
    parent ccddef...

    fix(BUG-1245): my ai fixed it

Continue to `cat-file -p $TREE` and you'll get:

    file efef12... Makefile
    tree a1b2c3... src/
    file f0ea12... README.md

...and then it's turtles all the way down. It is (was!) safe to sign $HEAD (and only head!) because... it's turtles all the way down. Signing HEAD attaches IDENTITY (eg; [email protected]) to CONTENT (eg: src/@a1b2c3...) and TRANSITIVELY all the way down.

Your homework is to go run:

    time (
      git ls-files | xargs -n 1 sha256sum
    ) | sha256sum

...and then make a commit (nee: tag/note) containing that content as the commit message.

Your INSTINCT isn't wrong, your mechanics run counter to the practicalities of how git is designed to work, and the practicalities of the crucial defense that git-core is trying to divert: the ability to arbitrarily alter the signed(!!!) past, signed by third parties, with $ELDRITCH_SHA1 attacks.

You _still_ have to trust that GitHub.com or kernel.org won't get popped and start erroneously serving "signed but faulty" files and trees, but the urgency of moving to sha256 is about preventing faulty commits in the first place, which removes the requirement of "trust me bro!" relationship with the serving provider (or MITM).