That’s not how git works. You can just verify a single commit hash you are interested in to ensure it matches what you expect. The reason for that is:
For
git, the fundamental data unit is a commit. Each commit object contains the hash of its parent commit(s). Changing an old commit would change its hash, and thus invalidate the hashes of all subsequent commits that reference it. This creates a cryptographically secure, historical chain (or Directed Acyclic Graph - DAG) of changes.
There is no way to change something in the past without affecting subsequent commit hashes, unless you found a hash collision; that would be pretty big news on its own.
Another practical reason that changing past tags won’t be an issue is that F-Droid has very limited resources, running on a tight budget. They only build the latest tagged release.
For example, look at this KeePass DX version history (another great software, btw):
Version 4.2.2 (147) isn’t available on F-Droid. This is because while it was queuing for a build, Version 4.2.3 was released just before 4.2.2 started building, causing F-Droid to skip the version. Naturally, they also don’t rebuild any retagged changes in the past versions.
Overall, I think what Lobi said is good enough for the intended audience.