Task #3576
openThe commit hash linkifier in git.libreoffice.org does not recognize the project, and always points to core
0%
Description
See https://git.libreoffice.org/core/+/90020e670e543bbcd54598eb62b43a5e996de0d1. It references a commit hash from another project (help), but the linkifier points to non-existing commit under core.
The linkifier should be made a bit smarter. It could check if the hash actually exists (no idea how sane, since that would incur an overhead, which possibly could be lessened by caching), or it could analyze the commit text, which is uniform for special commits like that one (but the latter option would not help for hypothetical cases when manual commit message would include hash from another project).
Also maybe make the linkifier recognize shortened hashes, as in https://git.libreoffice.org/core/+/83d599fd7c530d14f70ac60bd673b66640191bf7 referencing "6810aa937caca1". Using that shortened hash is possible in URL like https://git.libreoffice.org/core/+/6810aa937caca1. This would likely also imply some check for existence.
Updated by Florian Effenberger over 2 years ago
- Assignee set to Christian Lohmaier
Christian, is this something for you?
Updated by Christian Lohmaier over 2 years ago
- Target version set to Q2/2022
first I though it would be for IZBot, where it would be easy to do - for git.libreoffice.org website it also should be doable
Updated by Guilhem Moulin over 2 years ago
- Assignee changed from Christian Lohmaier to Guilhem Moulin
- Target version deleted (
Q2/2022)
Florian Effenberger wrote in #note-1:
Christian, is this something for you?
Claiming that since I maintain the gitiles patches for TDF and wrote all the server-side Lua logic for pretty links.
Not a good idea to do it in git.libreoffice.org/$PROJECT/+, that would potentially imply a large number of subrequests and seriously drain performance… Best to avoid producing such links in the first place. The fallback logic could be implemented server-side at https://git.libreoffice.org/-/commit/$COMMIT_ID or similar, but let's pretty please leave git.libreoffice.org/$PROJECT/+… alone.
Mike Kaganski wrote:
Also maybe make the linkifier recognize shortened hashes, as in https://git.libreoffice.org/core/+/83d599fd7c530d14f70ac60bd673b66640191bf7 referencing "6810aa937caca1". Using that shortened hash is possible in URL like https://git.libreoffice.org/core/+/6810aa937caca1. This would likely also imply some check for existence.
Shortened hashes without repo name is tricky due to the risk of collisions. For a given repo git is able to find the shortest prefix that allows a commit ID to be resolved without collision, but of course there is no guaranty of being collision-free in other repos. (git can shorten IDs down to 7 hex digits and will likely do so in smaller repos. It could for instance unambiguously shorten deadbeefdeadbeefdeadbeefdeadbeefdeadbeef to deadbee within lode.git, but globally deadbee is ambiguous if say core.git has a commit deadbee000000000000000000000000000000000. What it'll resolves to depends on whether core.git is queried before lode.git.) Anyway links are generated server-side and AFAIK gitiles doesn't have the ability to do subrequests needed to support shortened links (concretely, linkify <a href="/help/+/72eb5901a18fba63f13f832ac5e2082fd2d1f305">72eb5901a1</a> in the https://git.libreoffice.org/core/+/90020e670e543bbcd54598eb62b43a5e996de0d1 commit message).
Patching gitiles to blindly linkify as <a href="/-/commit/72eb5901a18fba63f13f832ac5e2082fd2d1f305">72eb5901a18fba63f13f832ac5e2082fd2d1f305</a> is probably doable.