When checking out a repository with full history, a full clone is done
and then the ref is finally updated to point to the commit that caused
the workflow to be run. Normally, this is a good protection against
someone pushing to the repository twice in short succession, but it
causes problems with annotated tags.
Specifically, because the entry in refs/tags is set to the commit hash,
if an annotated tag was used, the tag is turned merely into a
lightweight one, which breaks `git describe`. Every other tag in the
repository will continue to remain a valid annotated tag except the one
for which the workflow was invoked, which is not what the user expected.
Let's work around this by not performing a fetch if what we're fetching
is a tag. Technically, annotated tags can be anywhere in the hierarchy
at any ref, but this should work as a suitable heuristic for now.
Note that the proper solution would be to expose the revision of the
actual object and check against that instead of the commit, but it
doesn't presently appear that that information is exposed. Also, we
explicitly do not case-fold since Git refs are case sensitive.
