Issue reference backlinks are missing #1965

New Issue

GiteaMirror · 2025-11-02T04:19:34-06:00

GiteaMirror commented

2025-11-02 04:19:34 -06:00

Originally created by @stevegt on GitHub (Jun 23, 2018).

As of 85414d8b we're missing the "{user} referenced this issue {date}" backlinks that github creates when another issue references the current one. I'll link this issue to #3134 and vice versa so both show an example of what these should look like -- see below.

These links are pretty important; they turn github issues from disjoint threads into an interlinked, multi-threaded mesh. They help to prevent and converge duplicates, and probably have a role in community-building.

In my own case, as soon as we had created more than a few issues and users in our local Gitea install, I immediately started wanting these backlinks. This is the sort of problem that #1029 exposes.

I'm trying to figure out the right way to tackle this; do we somehow detect and create the backlinks on the fly as we render the HTML? Or do we use a backlinks table that gets populated as the references are created? If the latter, we would want to scan through existing comments at migration to create the initial table content when upgrading from older versions, right?

Originally created by @stevegt on GitHub (Jun 23, 2018). As of 85414d8b we're missing the "{user} referenced this issue {date}" backlinks that github creates when another issue references the current one. I'll link this issue to #3134 and vice versa so both show an example of what these should look like -- see below. These links are pretty important; they turn github issues from disjoint threads into an interlinked, multi-threaded mesh. They help to prevent and converge duplicates, and probably have a role in community-building. In my own case, as soon as we had created more than a few issues and users in our local Gitea install, I immediately started wanting these backlinks. This is the sort of problem that #1029 exposes. I'm trying to figure out the right way to tackle this; do we somehow detect and create the backlinks on the fly as we render the HTML? Or do we use a backlinks table that gets populated as the references are created? If the latter, we would want to scan through existing comments at migration to create the initial table content when upgrading from older versions, right?

GiteaMirror added the issue/confirmed type/feature labels 2025-11-02 04:19:34 -06:00

GiteaMirror closed this issue

2025-11-02 04:19:34 -06:00

GiteaMirror commented

2025-11-02 04:19:35 -06:00

@cryptix commented on GitHub (Jul 26, 2018):

As of ... we're missing ..

I wonder why this is marked as a feature? The above sounds much more like a regression.

@cryptix commented on GitHub (Jul 26, 2018): > As of ... we're missing .. I wonder why this is marked as a _feature_? The above sounds much more like a regression.

GiteaMirror commented

2025-11-02 04:19:35 -06:00

@lafriks commented on GitHub (Jul 26, 2018):

@cryptix Gitea has never supported such feature so that can not be regression

@lafriks commented on GitHub (Jul 26, 2018): @cryptix Gitea has never supported such feature so that can not be regression

GiteaMirror commented

2025-11-02 04:19:35 -06:00

@cryptix commented on GitHub (Jul 26, 2018):

Thanks for the clearification.

@cryptix commented on GitHub (Jul 26, 2018): Thanks for the clearification.

GiteaMirror commented

2025-11-02 04:19:36 -06:00

@stale[bot] commented on GitHub (Jan 16, 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 (Jan 16, 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 04:19:36 -06:00

@cryptix commented on GitHub (Jan 16, 2019):

sorry for the meta-noise but should feature tracking issues really be considered stale?

I for one would really like to try gitea once these things are in.

@cryptix commented on GitHub (Jan 16, 2019): sorry for the meta-noise but should feature tracking issues really be considered stale? I for one would really like to try gitea once these things are in.

GiteaMirror commented

2025-11-02 04:19:36 -06:00

@mxmehl commented on GitHub (Jun 5, 2019):

Do I see correctly that this issue would be solved with #3695 being merged?

@mxmehl commented on GitHub (Jun 5, 2019): Do I see correctly that this issue would be solved with #3695 being merged?

GiteaMirror referenced this issue

2025-11-02 12:03:20 -06:00

[PR #1965] [MERGED] Fix uppercase default branch bug #16146

Sign in to join this conversation.