Fix 500 error on repos with no tags

[mrsdizzie]

#11846 Introduced feature to show exact tag on commit view. However if a repo has no tags at all git prints out a separate and unhandled error " No names found, cannot describe anything.":

gitea/modules/git/commit.go

Line 490 in bc4f7ba

if strings.Contains(err.Error(), "no tag exactly matches") {

Adding --always to the command makes it always use the error in the style of "fatal: no tag exactly matches" even if there are no tags at all.

Fixes #11869
Fixes #11868

[silverwind]

I wonder why we even call GetTagName when no tags exist?

[mrsdizzie]

I believe we don't know if a repo has tags or not in this context and if you can run a single command to both find that out and print the tag if so it's better than running two (one to look for tags in general, one to check commit for tag).

[silverwind]

You're right. This does fix the issue by causing git to trigger the other (expected) error:

$ git describe --tags --exact-match --tags HEAD
fatal: No names found, cannot describe anything.
$ git describe --tags --exact-match --tags --always HEAD
fatal: no tag exactly matches '148269db9f5ce7e81c29136a73069ad518dad779'

I think we actually want to ignore all errors printed to stderr for both GetBranchName and GetTagName and only process stdout, that way we're also not dependant on matching error strings.

[mrsdizzie]

Yes I suspect a more robust error handling not relying on a string is better (I know we do this in a lot of places with git).

This was just quick fix to avoid 500 for many commits

[zeripath]

There's no other way to handle git errors I'm afraid. That's why I spent so long to force them to always be in English.

[silverwind]

In some cases we do care about the error but in this case we probably don't. If there are no tags, we don't care about why git can't find them. I was thinking about adding a boolean flag ignoreErrors to GetTagName and GetBranchName that would omit passing err if given.

[CirnoT]

Thanks for the fix, really annoying