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 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

Obscurities

While implementing it, I noticed two weird things:

1. The gogit version already seems to always behave this way (didn't test it but traced the source code down)
2. The normal version had the same code but never set this behavior. For now, the link following is minimally invasive into the remaining code, we can still decide in the future if TreeEntry.getName() of the normal version should behave like TreeEntry.getName() of the gogit version

Open Questions

• Should the tooltip display the link filename or the filename of the link target?
  For now, it uses the link target to give the user an idea of where clicking on the link will lead.

[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?