Follow file symlinks in the UI to their target

[delvh]

Description

Previously, when you clicked on a symlink, a document was opened that only displayed <target>.
While this follows git's behavior of implementing symlinks, it is not user-friendly for users using the web UI to access a file.
Now, symlinks are resolved when you click on a link next to them, either until a file has been found or until we know that the link is dead.
When the link cannot be accessed, we fall back to the current behavior of showing the document containing the target.

Before

Screenshots

After

[delvh]

Trivia: If we merge this, we are even ahead of GitHub in terms of behavior as GitHub still shows the <target> document instead of the linked location.

[KN4CK3R]

Could you add a test for TryFollowingLinks()? (valid link, link outside repo, ...)

[delvh]

And the test promptly caught a bug.
Welp.
I understand what the problem is, but I have no idea how to fix it adequately:
The problem is that I use fullPath = cleanedRelativePath in getTreeEntryByPath:

link points to ../nar/hello in foo/bar/link_to_hello

Expected foo/nar/hello, got nar/hello

However, I have no idea how to implement fullPath = tree.BasePath + normalizedRelativePath.
Does the tree already store this information?

[delvh]

Does the tree already store this information?

As expected, it doesn't 😒
What would be the most maintainable way to get the tree to store this information reliably?

[wxiaoguang]

After reading the code, I have some new ideas, maybe more simple to do: backend does nothing, but let frontend navigate.

For example:

• There is a link in repo: /foo/bar/link => ../aaa/bbb
• The UI just renders <a href="/org/repo/src/branch/main/foo/bar/../aaa/bbb">link</a>. Then when user clicks the link, they should be navigated to https://.../src/branch/main/foo/aaa/bbb

Otherwise, if we really would like to resolve the link in backend, I guess it needs some big refactoring to make things clear.

[delvh]

@wxiaoguang the problem with the frontend approach is that the frontend cannot recursively resolve links (latest-changelog -> /b-dir/current.txt -> /doc/internal/changes-2.30.2.md).
Apart from that, yes, it would be possible.

[wxiaoguang]

@wxiaoguang the problem with the frontend approach is that the frontend cannot recursively resolve links (latest-changelog -> /b-dir/current.txt -> /doc/internal/changes-2.30.2.md). Apart from that, yes, it would be possible.

For me, I would like to see the direct link target on the UI, instead of recursively resolving the links ahead. For example: suppose there is a link /foo -> /bar -> /aaa -> /bbb. As an end user, I would like to see /foo points to /bar, that's also the real filesystem shows to end users (eg: ls -l). I don't expect it shows /foo points to /bbb directly, that's somewhat counter-intuitive IMO.

---

If an end user would like to follow, the frontend approach could also work: use a href like /bar?follow_symlink=1, then if backend reads follow_symlink, it redirects to the next target /aaa?follow_symbol=1 and again and agian.

[delvh]

But what is it you want to achieve when you click on a (symlinked) file?
In 99,9% of cases, you want to see/edit the content that is linked, not go on a journey to find the actual file.

[wxiaoguang]

But what is it you want to achieve when you click on a (symlinked) file?
In 99,9% of cases, you want to see/edit the content that is linked, not go on a journey to find the actual file.

I updated the previous comment, a "/bar?follow_symlink=1" trick could work IMO.

[wxiaoguang]

Are you working on this at the moment?

[wxiaoguang]

@delvh is there still anything to improve?

[delvh]

A quick skim over your changes looked good.
Will need to test it when I find the time, which should be tomorrow.
If the PR isn't merged until then, I'll update the description once I've re-tested it with up-to-date screenshots.
But yeah, nothing holding the PR back from my side.

[delvh]

So, I tested it out now and pushed a small fix.
It works as expected for now.
However, I can imagine a couple of improvements further down the line in future PRs:

1. Display some sort of error when the link does not work
2. Enhance the tooltip to show exactly where the link will lead
3. Also add the same button when viewing the symlink directly or in a PR diff

[GiteaBot]

@delvh please fix the merge conflicts. 🍵