Github Mirrors and Wiki #965

New Issue

GiteaMirror · 2025-11-02T03:43:28-06:00

GiteaMirror commented

2025-11-02 03:43:28 -06:00

Originally created by @IzzySoft on GitHub (Aug 14, 2017).

Gitea version (or commit ref): 1.1.3
Git version: 2.7.4
Operating system: Bananian (Debian on ARM)
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

I've set up a couple of mirrors from Github. If they have a Wiki when the mirror is created, it comes along (I didn't check yet if such a wiki is updated later). But if the Wiki is added later, future syncs don't seem to pick it up. Is there any step I've missed, or anything I can do to have Gitea picking it up – apart from deleting the mirror and creating a new one?

Originally created by @IzzySoft on GitHub (Aug 14, 2017). - Gitea version (or commit ref): 1.1.3 - Git version: 2.7.4 - Operating system: Bananian (Debian on ARM) - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ ] Not relevant - Log gist: ## Description I've set up a couple of mirrors from Github. If they have a Wiki when the mirror is created, it comes along (I didn't check yet if such a wiki is updated later). But if the Wiki is added later, future syncs don't seem to pick it up. Is there any step I've missed, or anything I can do to have Gitea picking it up – apart from deleting the mirror and creating a new one?

GiteaMirror added the issue/confirmed type/enhancement labels 2025-11-02 03:43:28 -06:00

GiteaMirror commented

2025-11-02 03:43:28 -06:00

@lunny commented on GitHub (Aug 16, 2017):

Maybe a bug I think.

@lunny commented on GitHub (Aug 16, 2017): Maybe a bug I think.

GiteaMirror commented

2025-11-02 03:43:28 -06:00

@IzzySoft commented on GitHub (Aug 16, 2017):

Seems like. I've meanwhile verified two things:

if the wiki was active to begin with, it is mirrored correctly (so updates are pulled in)
simply creating a mirror by hand doesn't help, it is not picked up (and I could not figure where to make the connection)

Sure, only being a "read-only mirror" one could simply drop and recreate it, but (especially for large repositories and on slow connections) this would be an ugly work-around 😉

@IzzySoft commented on GitHub (Aug 16, 2017): Seems like. I've meanwhile verified two things: * if the wiki was active to begin with, it is mirrored correctly (so updates are pulled in) * simply creating a mirror by hand doesn't help, it is not picked up (and I could not figure where to make the connection) Sure, only being a "read-only mirror" one could simply drop and recreate it, but (especially for large repositories and on slow connections) this would be an ugly work-around :wink:

GiteaMirror commented

2025-11-02 03:43:29 -06:00

@bkcsoft commented on GitHub (Aug 24, 2017):

Not a bug, since we only verify that the remote repo (the wiki in this case) exists when we start the import. Enhancement though 🙂

Basically, show a "try import wiki"-button IF the repo is a mirror AND does not have a wiki setup.
Maybe even have that button beside the "Create new wiki"-button on the wiki-page 🤔

@bkcsoft commented on GitHub (Aug 24, 2017): Not a bug, since we only verify that the remote repo (the wiki in this case) exists when we start the import. Enhancement though 🙂 Basically, show a "try import wiki"-button IF the repo is a mirror AND does not have a wiki setup. Maybe even have that button beside the "Create new wiki"-button on the wiki-page 🤔

GiteaMirror commented

2025-11-02 03:43:29 -06:00

@IzzySoft commented on GitHub (Aug 24, 2017):

Bug, enhancement, feature … call it what you like as long as it works 😁

And yes, such a button would be a good start. Though I think it could not hurt to automatically check for the existence of a wiki on each sync run. Gitea doesn't ask whether to look for it on the initial run either (and that's very OK this way), so I wouldn't expect I need to do so later. Instead of that button, I'd rather suggest a checkbox (on the first import screen and then later on the config screen of that repo) on whether I'm interested in the wiki. So one can always change one's mind.

@IzzySoft commented on GitHub (Aug 24, 2017): Bug, enhancement, feature … call it what you like as long as it works :grin: And yes, such a button would be a good start. Though I think it could not hurt to automatically check for the existence of a wiki on each sync run. Gitea doesn't ask whether to look for it on the initial run either (and that's very OK this way), so I wouldn't expect I need to do so later. Instead of that button, I'd rather suggest a checkbox (on the first import screen and then later on the config screen of that repo) on whether I'm interested in the wiki. So one can always change one's mind.

GiteaMirror commented

2025-11-02 03:43:29 -06:00

@bkcsoft commented on GitHub (Aug 27, 2017):

Though I think it could not hurt to automatically check for the existence of a wiki on each sync run

Actually it could. Polling invalid repos on GitHub will get you rate-limited 🙁

@bkcsoft commented on GitHub (Aug 27, 2017): > Though I think it could not hurt to automatically check for the existence of a wiki on each sync run Actually it could. Polling invalid repos on GitHub will get you rate-limited 🙁

GiteaMirror commented

2025-11-02 03:43:29 -06:00

@bkcsoft commented on GitHub (Aug 27, 2017):

Instead of that button, I'd rather suggest a checkbox (on the first import screen and then later on the config screen of that repo) on whether I'm interested in the wiki. So one can always change one's mind.

Sounds like a good idea though 🙂

@bkcsoft commented on GitHub (Aug 27, 2017): > Instead of that button, I'd rather suggest a checkbox (on the first import screen and then later on the config screen of that repo) on whether I'm interested in the wiki. So one can always change one's mind. Sounds like a good idea though 🙂

GiteaMirror commented

2025-11-02 03:43:29 -06:00

@IzzySoft commented on GitHub (Aug 29, 2017):

Actually it could. Polling invalid repos on GitHub will get you rate-limited

Oh, wasn't aware of that. Which means it would need a kind of flag like "already checked today, there is no wiki – check again tomorrow" or the like, to prevent that. Until a "perfect approach" is found, that button would be helpful already (and not necessarily obsolete thereafter).

@IzzySoft commented on GitHub (Aug 29, 2017): > Actually it could. Polling invalid repos on GitHub will get you rate-limited Oh, wasn't aware of that. Which means it would need a kind of flag like "already checked today, there is no wiki – check again tomorrow" or the like, to prevent that. Until a "perfect approach" is found, that button would be helpful already (and not necessarily obsolete thereafter).

GiteaMirror commented

2025-11-02 03:43:30 -06:00

@IzzySoft commented on GitHub (Jan 29, 2018):

Half a year later (I'm running Gitea 1.3.2 now): Did I miss the button, or did you miss adding it? I meanwhile lost track of which repos are simply lacking wikis on both ends, or which I have to trigger for sync. And there are several repos in my installation where I know I have to initiate the mirror – but apart from dropping the mirror entirely and recreating it, I still have no idea how to get it running.

TL;DR: any progress on this?

@IzzySoft commented on GitHub (Jan 29, 2018): Half a year later (I'm running Gitea 1.3.2 now): Did I miss the button, or did you miss adding it? I meanwhile lost track of which repos are simply lacking wikis on both ends, or which I have to trigger for sync. And there are several repos in my installation where I know I have to initiate the mirror – but apart from dropping the mirror entirely and recreating it, I still have no idea how to get it running. **TL;DR:** any progress on this?

GiteaMirror commented

2025-11-02 03:43:30 -06:00

@bkcsoft commented on GitHub (Feb 10, 2018):

No one is working on it. Feel free to contribute. People mainly work on bugs that they want/need to fix :/

@bkcsoft commented on GitHub (Feb 10, 2018): No one is working on it. Feel free to contribute. People mainly work on bugs that they want/need to fix :/

GiteaMirror commented

2025-11-02 03:43:30 -06:00

@IzzySoft commented on GitHub (Jun 18, 2018):

@bkcsoft I'd feel free if time would permit – and if I'd be a GO programmer. Got a bunch of other projects to care for, and I'm not a GO programmer – so unfortunately I can't.

@IzzySoft commented on GitHub (Jun 18, 2018): @bkcsoft I'd feel free if time would permit – and if I'd be a GO programmer. Got a bunch of other projects to care for, and I'm not a GO programmer – so unfortunately I can't.

GiteaMirror commented

2025-11-02 03:43:30 -06:00

@stale[bot] commented on GitHub (Jan 23, 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 23, 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 03:43:30 -06:00

@IzzySoft commented on GitHub (Jan 24, 2019):

Oh dear bot, have mercy with the devs and grant them some more time 🤣

(sorry, couldn't resist)

@IzzySoft commented on GitHub (Jan 24, 2019): Oh dear bot, have mercy with the devs and grant them some more time 🤣 (sorry, couldn't resist)

GiteaMirror commented

2025-11-02 03:43:30 -06:00

@linkp commented on GitHub (May 28, 2019):

If this enhancement request ever does find it's way in as a feature, it would be nice to have an option to not import a wiki as part the same setting during mirror creation.

I can only find an option to disable the wiki after the mirror is created and I have a GithHub mirror that is failing after logging: [W] Clone wiki: exit status 128 - fatal: Remote branch master not found in upstream origin

I would love to have an option to test mirroring with the wiki disabled to see if that resolves the early termination of the mirroring process.

@linkp commented on GitHub (May 28, 2019): If this enhancement request ever does find it's way in as a feature, it would be nice to have an option to not import a wiki as part the same setting during mirror creation. I can only find an option to disable the wiki after the mirror is created and I have a GithHub mirror that is failing after logging: [W] Clone wiki: exit status 128 - fatal: Remote branch master not found in upstream origin I would love to have an option to test mirroring with the wiki disabled to see if that resolves the early termination of the mirroring process.

GiteaMirror commented

2025-11-02 03:43:31 -06:00

@lesinigo commented on GitHub (Jul 2, 2020):

I'd add that it would be cool to be able to decide if the wiki is to be mirrored at all or not.

Use case: I want to mirror a git repository, but want to have my own wiki for my own notes / documentation.

Possible implementation:

when creating the migration / mirror, ask the user if the Wiki should be migrated / mirrored
if it's a migration, then everything goes on as usual
if it is a mirror with mirrored wiki, it will stay as it is without further options
if it is a mirror without mirrored wiki, allow to turn on Build-In or External wiki like on regular projects (and keep ignoring the remote wiki forever)

If the user changes his mind and wants to mirror the wiki when it didn't choose so (or the other way around), simply drop the project and re-create it.

@lesinigo commented on GitHub (Jul 2, 2020): I'd add that it would be cool to be able to decide if the wiki is to be mirrored at all or not. Use case: I want to mirror a _git repository_, but want to have my own wiki for my own notes / documentation. Possible implementation: * when creating the migration / mirror, ask the user if the Wiki should be migrated / mirrored * if it's a migration, then everything goes on as usual * if it is a mirror with mirrored wiki, it will stay as it is without further options * if it is a mirror without mirrored wiki, allow to turn on Build-In or External wiki like on regular projects (and keep ignoring the remote wiki forever) If the user changes his mind and wants to mirror the wiki when it didn't choose so (or the other way around), simply drop the project and re-create it.

GiteaMirror commented

2025-11-02 03:43:31 -06:00

@wohenbushuang commented on GitHub (Jan 19, 2021):

Use case: I want to mirror a git repository, but want to have my own wiki for my own notes / documentation.

Same issue when I found that I cannot create my notes to a mirror repository, even if I re-open/close the wiki function in repository settings, it won't show any button to create a new wiki page in the wiki tab

@wohenbushuang commented on GitHub (Jan 19, 2021): > Use case: I want to mirror a git repository, but want to have my own wiki for my own notes / documentation. Same issue when I found that I cannot create my notes to a mirror repository, even if I re-open/close the wiki function in repository settings, it won't show any button to create a new wiki page in the wiki tab

GiteaMirror referenced this issue

2025-11-02 11:52:17 -06:00

[PR #965] [MERGED] refactor: update debian script. #15685

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#965