mirrored repositories do not carry over issues/PRs data #3475

New Issue

GiteaMirror · 2025-11-02T05:13:58-06:00

GiteaMirror commented

2025-11-02 05:13:58 -06:00

Originally created by @bryanpedini on GitHub (Jun 16, 2019).

Gitea version (copied from try.gitea.io): 1.9.0+dev-353-gcf2221e3a
Git version: IDK what u use there..
Operating system: IDK either
Database: IDK either
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL): https://try.gitea.io/bryanpedini/gitea/issues/7196
- No
- Not relevant
Log gist: !?

Description

I don't know if this is intentional / a real "feature", but when mirroring a repository the data concerning issues / PRs do not carry over to the mirror, which, being a mirror should mirror everything (right?).

Title / bug could totally be the inverse, being that this is a feature and the real bug is on the commit screen.
Better explaination: I notices this on the ZXQ Labs Gitea server of @thehowl (an in real life friend of mine), where he mirrored a videogame repo, and by going into the commit history everything seems clean (# are not links, because Gitea understands that there isn't a issue page under that: proof), however by going into the page of the single commit, magically that becomes a link, not of the remote (mirrored) server (say for example GitHub), but of the local mirror, which of course has no single issue / PR related page: as you can view here.

Three different very acceptable solutions would be

to remove the link from the single commit page (this one)
to REGEX the original URL of the mirror and link the issue to the "original" server (the one from which you mirror), but then it would be nice to include the same feature in the commit history too (here)
less practicable but most "complete": build and integrate with the existing syncronization framework, the sync that is needed to fetch issues / PRs data alongside code, commits and branches

Originally created by @bryanpedini on GitHub (Jun 16, 2019). - Gitea version (copied from try.gitea.io): 1.9.0+dev-353-gcf2221e3a - Git version: IDK what u use there.. - Operating system: IDK either - Database: IDK either - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (provide example URL): https://try.gitea.io/bryanpedini/gitea/issues/7196 - [ ] No - [ ] Not relevant - Log gist: _!?_ ## Description I don't know if this is intentional / a real "feature", but when mirroring a repository the data concerning issues / PRs do not carry over to the mirror, which, being a mirror should mirror everything (right?). Title / bug could totally be the inverse, being that this is a feature and the real bug is on the commit screen. Better explaination: I notices this on the ZXQ Labs Gitea server of @thehowl (an in real life friend of mine), where he mirrored a videogame repo, and by going into the commit history everything seems clean (# are not links, because Gitea understands that there isn't a issue page under that: [proof](https://try.gitea.io/bryanpedini/gitea/commits/branch/master)), however by going into the page of the single commit, magically that becomes a link, not of the remote (mirrored) server (say for example GitHub), but of the local mirror, which of course has no single issue / PR related page: as you can view [here](https://try.gitea.io/bryanpedini/gitea/commit/cf2221e3acce4d2c88c09976557ce3e73068baaf). Three different very acceptable solutions would be - to remove the link from the single commit page ([this one](https://try.gitea.io/bryanpedini/gitea/commit/cf2221e3acce4d2c88c09976557ce3e73068baaf)) - to REGEX the original URL of the mirror and link the issue to the "original" server (the one from which you mirror), but then it would be nice to include the same feature in the commit history too ([here](https://try.gitea.io/bryanpedini/gitea/commits/branch/master)) - less practicable but most "complete": build and integrate with the existing syncronization framework, the sync that is needed to fetch issues / PRs data alongside code, commits and branches

GiteaMirror added the issue/confirmed type/enhancement labels 2025-11-02 05:13:58 -06:00

GiteaMirror closed this issue

2025-11-02 05:13:58 -06:00

GiteaMirror commented

2025-11-02 05:13:59 -06:00

@bryanpedini commented on GitHub (Jun 16, 2019):

Hook me or @thehowl up (if he is willing and not busy / lazy with anything else) to try to help up with the code if ever needed!

@bryanpedini commented on GitHub (Jun 16, 2019): Hook me or @thehowl up (if he is willing and not busy / lazy with anything else) to try to help up with the code if ever needed!

GiteaMirror commented

2025-11-02 05:13:59 -06:00

@stale[bot] commented on GitHub (Aug 15, 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 (Aug 15, 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:14:00 -06:00

@bryanpedini commented on GitHub (Apr 23, 2020):

Any update yet?
It could have been useful when you migrated some Gitea modules on Gitea too...

Thanks in advance.

@bryanpedini commented on GitHub (Apr 23, 2020): Any update yet? It could have been useful when you migrated some Gitea modules on Gitea too... Thanks in advance.

GiteaMirror commented

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

@lafriks commented on GitHub (Apr 24, 2020):

Migration does support issues and PR. For mirrors it would be hard to sync issues and PR all the time as that would require scanning all issues and PR all the time for changes

@lafriks commented on GitHub (Apr 24, 2020): Migration does support issues and PR. For mirrors it would be hard to sync issues and PR all the time as that would require scanning all issues and PR all the time for changes

GiteaMirror commented

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

@bryanpedini commented on GitHub (Apr 24, 2020):

Isn't there an API endpoint to issue a scan of a repo, only beginning at a cerain offset?
Like the machine language for "get me all issues after ID 701" or something like that?

@bryanpedini commented on GitHub (Apr 24, 2020): Isn't there an API endpoint to issue a scan of a repo, only beginning at a cerain offset? Like the machine language for "get me all issues after ID 701" or something like that?

GiteaMirror commented

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

@lafriks commented on GitHub (Apr 24, 2020):

But PR can be closed/repoened/commented etc, so you can't just check for new ones

@lafriks commented on GitHub (Apr 24, 2020): But PR can be closed/repoened/commented etc, so you can't just check for new ones

GiteaMirror commented

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

@bryanpedini commented on GitHub (Apr 24, 2020):

That's right... Fair enough...
But come on; it's GitHub, it HAS to have an endpoint that accepts things like "only changed" or "only new" as request parameters...
Am I wrong here?

@bryanpedini commented on GitHub (Apr 24, 2020): That's right... Fair enough... But come on; it's GitHub, it HAS to have an endpoint that accepts things like "only changed" or "only new" as request parameters... Am I wrong here?

GiteaMirror commented

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

@lafriks commented on GitHub (Apr 24, 2020):

I don't think there is

@lafriks commented on GitHub (Apr 24, 2020): I don't think there is

GiteaMirror commented

2025-11-02 05:14:01 -06:00

@bryanpedini commented on GitHub (Apr 24, 2020):

Damn it...
Close the issue then if there is nothing doable here, it would have been nice, but whatever - we can totally live without

@bryanpedini commented on GitHub (Apr 24, 2020): Damn it... Close the issue then if there is nothing doable here, it would have been nice, but whatever - we can totally live without

GiteaMirror commented

2025-11-02 05:14:01 -06:00

@bryanpedini commented on GitHub (Apr 24, 2020):

Thanks for your time at least.
Great to see support from the devs

@bryanpedini commented on GitHub (Apr 24, 2020): Thanks for your time at least. Great to see support from the devs

GiteaMirror referenced this issue

2025-11-02 12:22:58 -06:00

[PR #3475] [MERGED] Add EUPL v1.2 as license #16957

Sign in to join this conversation.