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.

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

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 usefullPath = cleanedRelativePath ingetTreeEntryByPath:

link points to../nar/hello infoo/bar/link_to_hello

Expectedfoo/nar/hello, gotnar/hello

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

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?

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 tohttps://.../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.

@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 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 readsfollow_symlink, it redirects to the next target/aaa?follow_symbol=1 and again and agian.

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.

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.

Are you working on this at the moment?

@delvh is there still anything to improve?

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.

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

@delvh please fix the merge conflicts. 🍵