Resolving relative symlinks #3936

New Issue

GiteaMirror · 2025-11-02T05:31:06-06:00

GiteaMirror commented

2025-11-02 05:31:06 -06:00

Originally created by @hughesjs on GitHub (Sep 11, 2019).

It is often desirable to use symlinks in projects where the language dictates all source files must be in the same folder. That way, you can design individual modules in separate folders and then symlink them into the main directory.

Symlinks get captured by git just fine. However, it would be nice if gitea made some effort to resolve them.

For instance, my project directory could look like this:

Where debounce and the prescaler are there own modules with their own testbenches etc. Then when I go into the fourcounter folder (the main project using the submodules), I can symlink the relevant VHD files in so that we don't end up with a situation where changes to one aren't reflected in the other.

Unfortunately, the handling of symlinks is very rudimentary. I believe it would be advantageous if Gitea could look at a symlink, attempt to resolve it to a file in the repo and then link to it properly rather than just giving the symlink directory.

This should be simple for relative symlinks and with a bit of extra work even full-path symlinks could be parsed by working backwards from the deepest directory to determine the common part of the path that belongs to the repo.

Thoughts?

Originally created by @hughesjs on GitHub (Sep 11, 2019). It is often desirable to use symlinks in projects where the language dictates all source files must be in the same folder. That way, you can design individual modules in separate folders and then symlink them into the main directory. Symlinks get captured by git just fine. However, it would be nice if gitea made some effort to resolve them. For instance, my project directory could look like this: ![image](https://user-images.githubusercontent.com/4203766/64688309-01a6f000-d484-11e9-93f3-ba28d7a25e18.png) Where debounce and the prescaler are there own modules with their own testbenches etc. Then when I go into the fourcounter folder (the main project using the submodules), I can symlink the relevant VHD files in so that we don't end up with a situation where changes to one aren't reflected in the other. ![image](https://user-images.githubusercontent.com/4203766/64688442-42066e00-d484-11e9-8898-01c7414be32d.png) Unfortunately, the handling of symlinks is very rudimentary. I believe it would be advantageous if Gitea could look at a symlink, attempt to resolve it to a file in the repo and then link to it properly rather than just giving the symlink directory. ![image](https://user-images.githubusercontent.com/4203766/64688537-74b06680-d484-11e9-83a7-75d38a72750a.png) This should be simple for relative symlinks and with a bit of extra work even full-path symlinks could be parsed by working backwards from the deepest directory to determine the common part of the path that belongs to the repo. Thoughts?

GiteaMirror added the issue/stale label 2025-11-02 05:31:06 -06:00

GiteaMirror closed this issue

2025-11-02 05:31:07 -06:00

GiteaMirror commented

2025-11-02 05:31:08 -06:00

@lunny commented on GitHub (Sep 12, 2019):

Which gitea version are you using?

@lunny commented on GitHub (Sep 12, 2019): Which gitea version are you using?

GiteaMirror commented

2025-11-02 05:31:08 -06:00

@hughesjs commented on GitHub (Sep 12, 2019):

1.8.3

@hughesjs commented on GitHub (Sep 12, 2019): 1.8.3

GiteaMirror commented

2025-11-02 05:31:08 -06:00

@stale[bot] commented on GitHub (Nov 11, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Nov 11, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 05:31:08 -06:00

@stale[bot] commented on GitHub (Nov 25, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Nov 25, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 12:27:36 -06:00

[PR #3936] [MERGED] Note about adding permisions to binary #17151

Sign in to join this conversation.