@todd_a_jacobs There _are_ things signatures can help with, but yeah OpenPGP has a pretty poor track record (of usability, among other things).
(As you point out, "all" it gives you is a way to say "these two things were probably signed by the same person"). That can still be useful, but there's never "an" answer to these things.
p.s. each Git commit is actually an _entire_ tree; the diff shown to you is done by the frontend.
@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
@meejah Nobody said it signed trees. However, it must sign something that represents a given treeish, or it hasn't signed anything useful. One assumes the signature includes the commit hash for the parent treeish as part of whatever other metadata is also being signed.
You're more or less reinforcing my point: the question of exactly what is being signed (hand-waving it as "the commit" or "a tag" is semantically null since both contain various attributes and metadata) is something that even people well-versed in both GPG and Git generally can't answer canonically without delving into the source code.
We're not disagreeing. You and I are just pointing out the same problem in different ways IMHO.
@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
