Incorrect Commit Hash Linking

[jag3773]

• Gitea version (or commit ref): 1.9.0+dev-370-gde9b398cd
• Git version: NA
• Operating system: Web display issue, seen on Firefox and Chrome on Windows and Mac
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (https://try.gitea.io/jag3773/testing/src/branch/master/README.md)
• Log gist:

Description

Gitea is linking the Croatian word for alphabet (abeceda) to a non-existent commit hash in Markdown files. For example, see https://try.gitea.io/jag3773/testing/src/branch/master/README.md . The links therein point at https://try.gitea.io/jag3773/testing/commit/abeceda .

Screenshots

[zeripath]

It'd also do it to deadbee feedbee dadbeef acefeed acebeef and so on...

[zeripath]

I guess the problem is how to detect whether these are valid short shas. I wonder if when rendering the comment GitHub is checking if the codes are valid short shas eg de9b398 should be a valid short sha but I suspect that de9b398d isn't

[zeripath]

What we really need is a way of telling Gitea not to process some of these things it auto processes. Personally I'd be a fan of a preceding \ but I don't know how easy that would be to implement

[mrsdizzie]

Github does check if they are actual commits or not, which I think is the only real solution to this -- though that probably means some sort of DB lookup when rendering matches. Not sure if that is possible/reasonable within the current way of doing things? I know there has been an effort to avoid that.

These are really a problem with blocks of existing text, and having to always edit anything that matches a pattern and actually modify the contents so it doesn't generate a link doesn't seem like a solution.

[jag3773]

Another workaround idea would be to only check for commit hashes in issue threads and not in regular markdown files in the repository–operating on the theory that it's less likely you'll be referring to a commit hash in your markdown files. Of course, that could be changing behavior that someone may be relying on?

[mrsdizzie]

That would just trade one problem for another (and original problem would still exist in issues). Checking that the hash exists would need to be the final solution for this I think

[zeripath]

I still think that we need some way of telling Gitea not to try to interpret these. Sometimes you just want to refer to \#1 (and not issue #1). I don't even know how to stop this on GitHub!)

[mrsdizzie]

Yes agree, and that is the downside of auto linking in the first place :(

Most people probably don't want to modify their content as it would look strange in any other context (a text file that now has a bunch of \#1 in it). Again, if you are typing new content its easier to avoid by maybe putting a space or including a code block, but most people probably aren't going to want to modify all of their existing docs, text, etc... We could probably introduce a class that doesn't get run through the processor (link links and code now) and people could put blocks of text within that so it would be a little cleaner at least.

Though I think that is separate, as most of these issues are about creating links where there shouldn't be any (and pointing to a non existent commit/issue) rather than trying to disable it when it would otherwise be wanted.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[jag3773]

This seems to be fixed on the running build of try.gitea.io (Gitea Version: 1.10.0+dev-199-g9f58187f1)!