Inconsistency in bindings location and modules content. Wiki/Issue tracker handling. #1957

New Issue

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

GiteaMirror commented

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

Originally created by @tarelda on GitHub (Jun 21, 2018).

Gitea version (or commit ref): master
Git version: Not relevant
Operating system: Not relevant
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: Not relevant

Description

First some background. Recently, I had to migrate my old gitlab instance to something newer and chose gitea instead of newer gitlabs (honestly I just want my 16GB of RAM back). I used python to write migration script that was even able to extract and compact snippets. Unfortunately something I couldn't get around was handling wikis. I need them to be imported too, but there is no API endpoints for it (tried method with directly making requests to ui but was too inconsistent in behaviour). Then I stumbled upon #488 and mad me realize that the best way to do it is just patch API and my journey begun...

Thoughts concerning code

After a few hours spend walking through code I noticed two things that bothered me:

Bindings are located as well as in built-in auth module as in separate api module (I can't justify why it is separated).
Auth module contains quite a lot of forms that are not related to authorization.

My solutions:
Alternative 1. Move out of auth and api module all of the bindings into separate package named bindings.
Alternative 2. Essentially alternative 1, but auth related bindings and forms keep in the module.
Alternative 3. Create package forms and move all of the non-auth related forms there. Refactor API routers to use built-in api module which has bindings and handlers embedded.

Wiki/Issue tracker API situation

First of all, my main issue was with the fact that I needed to create page to have local wiki initialised. My proposition is that local wiki repo should be initialized when feature is enabled and deleted if disabled?
Secondly, where exactly handle Wiki/Issue tracker? My first idea was to just add PATCH request for /repos/{user|org}/{repo}, which is more compatible with github API.
But I find more appealing and CRUD friendly, creating two new endpoints /repos/{user|org}/{repo}/wiki , /repos/{user|org}/{repo}/issuetracker with appropriate set of handlers for methods GET and PATCH.
GET method would be used to determine which type of unit is enabled and PATCH to switch inbetween them.

Bottomline

I don't want waste my time working a code that won't be accepted by maintainers or community. So tell me what are your thoughts?

Originally created by @tarelda on GitHub (Jun 21, 2018). - Gitea version (or commit ref): master - Git version: Not relevant - Operating system: Not relevant - Database (use `[x]`): - [x] PostgreSQL - [x] MySQL - [x] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: Not relevant ## Description First some background. Recently, I had to migrate my old gitlab instance to something newer and chose gitea instead of newer gitlabs (honestly I just want my 16GB of RAM back). I used python to write migration script that was even able to extract and compact snippets. Unfortunately something I couldn't get around was handling wikis. I need them to be imported too, but there is no API endpoints for it (tried method with directly making requests to ui but was too inconsistent in behaviour). Then I stumbled upon #488 and mad me realize that the best way to do it is just patch API and my journey begun... ### Thoughts concerning code After a few hours spend walking through code I noticed two things that bothered me: 1. Bindings are located as well as in built-in auth module as in separate api module (I can't justify why it is separated). 2. Auth module contains quite a lot of forms that are not related to authorization. My solutions: Alternative 1. Move out of auth and api module all of the bindings into separate package named bindings. Alternative 2. Essentially alternative 1, but auth related bindings and forms keep in the module. Alternative 3. Create package forms and move all of the non-auth related forms there. Refactor API routers to use built-in api module which has bindings and handlers embedded. ### Wiki/Issue tracker API situation First of all, my main issue was with the fact that I needed to create page to have local wiki initialised. My proposition is that local wiki repo should be initialized when feature is enabled and deleted if disabled? Secondly, where exactly handle Wiki/Issue tracker? My first idea was to just add PATCH request for /repos/{user|org}/{repo}, which is more compatible with github API. But I find more appealing and CRUD friendly, creating two new endpoints /repos/{user|org}/{repo}/wiki , /repos/{user|org}/{repo}/issuetracker with appropriate set of handlers for methods GET and PATCH. GET method would be used to determine which type of unit is enabled and PATCH to switch inbetween them. ### Bottomline I don't want waste my time working a code that won't be accepted by maintainers or community. So tell me what are your thoughts?

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

GiteaMirror commented

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

@stale[bot] commented on GitHub (Jan 22, 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 22, 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 referenced this issue

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

[PR #1975] [CLOSED] Issue #1957 - Fix forwarding stdin to pre/post-receive scripts #16154

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#1957