@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