Commit Graph: Pull-Requests should not link to issues

[MarkusAmshove]

• Gitea version (or commit ref): 1.14.1

Description

With Gitea 1.14.0 and #12766 the commit graph (<repository-url>/graph) includes links to pull requests instead of the names of the ref's.

I like this change a lot, however I can't really use it, because my repositories use an external issue tracker.

The links associated with the pull requests are generated as: <repository-url>/issues/<pr-id>
The links would work if they were generated as: <repository-url>/pulls/<pr-id>

[zeripath]

I'm confused because these should have already been being redirected if Gitea was set up correctly.

[MarkusAmshove]

What do I have to configure in Gitea other than the external tracker in the repository?

If I configure an external tracker, e.g. Redmine, all pull reference links in Gitea (like the automated commit message in merges and now the graph) always redirect to Redmine when clicked, because they use the issue route and not the pulls route.

If changing those links to pulls is no option, then they shouldn't be generated as links in the first place when an external tracker is configured, because it is confusing

[MarkusAmshove]

By the way, the external tracker uses the same format as Gitea uses for issues/pr: #123

That's why all generated Gitea messages which reference pulls also redirect to the external tracker

[zeripath]

agh crap - now I remember - the external issue tracker vs external pull requests thing is not completely specified.

I think we need to pull in @wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf here. How have you configured this?

There has to be an explicit way of detecting what we should be linking to.

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

the thing is that sometimes you might actually want to link both issues and PRs externally - such as for a mirror.
you don't track issues for the mirror, much less PRs, you specify the external issue tracker (known format for GH, another Gitea instance, Gitlab...) and PRs get autolinked outside as well.
that's what I do for mirrors I set up, it's makes for a very convenient navigation flow.

but that's just one use case.

another one might be the one OP mentions, where issues are tracked externally but PR's are local.
to satisfy them both it might be smart to have a way of specifying whether it's desirable to also externally link PRs when external issue tracker is enabled.
it could, e.g., be unchecked by default for a mirror (no reason to track PRs) and this checkbox would only be available if external issue tracker is enabled (cause otherwise it makes no sense).

to summarize, I have my own way of using the feature but I recognize there's other uses for it, such as the one mentioned by OP.

EDIT: these are just ideas, I understand the implementation might actually be more complicated than this.

[zeripath]

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf do your repositories here have the pull requests feature turned off or still turned on?

Similarly @MarkusAmshove ?

It would be good to see a screenshot of the repository advanced settings sections, eg.:

(Clearly censored as necessary.)

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

here's mine for a github.com/go-gitea/gitea mirror

EDIT: note the cursor is hovering on the issue/PR link that points to GH.

[zeripath]

@MarkusAmshove I guess you have pullrequests enabled? If so that hunts at how the square may be circled and we can get a PR that solves both issues

[MarkusAmshove]

@MarkusAmshove I guess you have pullrequests enabled? If so that hunts at how the square may be circled and we can get a PR that solves both issues

I can't provide a screenshot yet, but yes:

• External issue tracker enabled
• Pull Requests enabled

[zeripath]

Cool there exists a solution that will make both situations work.