@meejah You're exactly right. The question is actually still have is around exactly what about the commit is signed. This is an implementation detail, and not really well-documented in the user docs. I'm sure it can verify the treeish, but whether it actually signs every piece of metadata associated with the commit is something I wasn't able to grok from the source, especially since you couldn't modify Git history if you can't change the pointer to the parent treeish in the DAG.

My current understanding is that you can still move commits, but you may either lose the signature because it's stripped when moved or you just get an invalid one signature if you try to verify the moved treeish. Either way, it solves nothing to do with xz-utils, but I'm still interested in the technical specifics of what's happening under the hood.

@todd_a_jacobs You don't sign trees, you sign commits (or tags). The commit hash includes the tree, author, parent(s), etc. This is why rebasing changes all the commit hashes, because the parent pointers change

@todd_a_jacobs Sorry, I should have put "hash" on the end of those; in my usage "commit" refers to "the commit hash" and "tag" refers also to "the commit hash".

I do agree the docs could be more clear on what _precisely_ is hashed to get the commit hash (and we do agree that Git's UX is "not great").

As with a lot of Git, you can also learn a bunch by just playing around with the files and so forth (instead of the source code). `git cat-file` can help here too