Web frontend: Commit message text is altered when creating commit hash links

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Summary

When viewing a commit message in the web frontend, words that match the beginning of a commit hash are expanded to 8 characters when displayed. This is inappropriate when it is coincidental that the words matches a commit hash.

Steps to reproduce

1. Make some commit and push it. Note the first seven characters of the commit hash.
2. Make and push another commit with a message that contains those seven characters as a standalone word somewhere.
3. View the second commit in the web frontend and see that the messages displays eight characters instead of seven.

Example Project

https://gitlab.com/zivarah/hash-link-repro reproduces this issue, specifically in the commit message for a59e8d073b55dd1b61e1ac01516ad00eec4a8616.

What is the current bug behavior?

When viewing a commit message in the web frontend, words that are recognized as commit hashes are expanded to 8 characters.

Under normal circumstances, this isn't particularly problematic. However, there can be cases where a non-hash value happens to match a commit hash. When this false-positive occurs, adding additional characters to the value displayed changes the meaning of the message.

For example, take this original commit message which has an issue ID as a trailer:

Some subject

Some additional content

Issue: 1234567

If there happens to be a commit with a hash starting with "1234567", this actually ends up displaying as:

Some subject

Some additional content

Issue: 12345678

Any user attempting to look up the issue by that ID is going to have a bad day. At best, it doesn't exist. At worst, it's the wrong issue entirely.

What is the expected correct behavior?

The displayed text should not be altered when showing the commit message to the user.

I think it's acceptable if these false-positive hash matches are displayed as links still -- that's probably not really viable to avoid.

Relevant logs and/or screenshots

reproduced on GitLab.com typebug