Proposal: Merge Git & SDK repos into main repo #2856

New Issue

GiteaMirror · 2025-11-02T04:51:37-06:00

GiteaMirror commented

2025-11-02 04:51:37 -06:00

Originally created by @techknowlogick on GitHub (Feb 4, 2019).

merge git & sdk into this repo. We can still keep same import path (code.gitea.io/git & code.gitea.io/sdk)

I recommend we use folders: modules/git & modules/sdk

Having the two extra repos creates a barrier for new contributions and multiple redundant PRs. Easier if all other two repos were in this one.

Thoughts?

Originally created by @techknowlogick on GitHub (Feb 4, 2019). merge git & sdk into this repo. We can still keep same import path (code.gitea.io/git & code.gitea.io/sdk) I recommend we use folders: modules/git & modules/sdk Having the two extra repos creates a barrier for new contributions and multiple redundant PRs. Easier if all other two repos were in this one. Thoughts?

GiteaMirror added the type/proposal type/refactoring labels 2025-11-02 04:51:37 -06:00

GiteaMirror closed this issue

2025-11-02 04:51:37 -06:00

GiteaMirror commented

2025-11-02 04:51:37 -06:00

@zeripath commented on GitHub (Feb 4, 2019):

I think in general this would be a good idea however, we will need to ensure that we somehow keep the external API stable for the SDK. So perhaps we could keep a testing suite outside of the current repo?

I would in particular be very keen to move them in because I think both git and the sdk are not getting updated properly (and I know I'm guilty of this)

@zeripath commented on GitHub (Feb 4, 2019): I think in general this would be a good idea however, we will need to ensure that we somehow keep the external API stable for the SDK. So perhaps we could keep a testing suite outside of the current repo? I would in particular be very keen to move them in because I think both git and the sdk are not getting updated properly (and I know I'm guilty of this)

GiteaMirror commented

2025-11-02 04:51:38 -06:00

@lunny commented on GitHub (Feb 5, 2019):

I totally wanted to proposal that before.

@lunny commented on GitHub (Feb 5, 2019): I totally wanted to proposal that before.

GiteaMirror commented

2025-11-02 04:51:38 -06:00

@bclermont commented on GitHub (Mar 10, 2019):

I just noticed that there is no test units for the API server (and go-sdk).

I experience few bugs in the go-sdk and I wanted to add tests for the api routers, which will be super easy to do when go-sdk is merged into main repo. Because I just need to implement tests for go-sdk and it will test both server and client.

Will wait until then to do that

@bclermont commented on GitHub (Mar 10, 2019): I just noticed that there is no test units for the API server (and go-sdk). I experience few bugs in the go-sdk and I wanted to add tests for the api routers, which will be super easy to do when go-sdk is merged into main repo. Because I just need to implement tests for go-sdk and it will test both server and client. Will wait until then to do that

GiteaMirror commented

2025-11-02 04:51:38 -06:00

@zeripath commented on GitHub (Mar 10, 2019):

Most of the api is tested in the integrations/ tests.

@zeripath commented on GitHub (Mar 10, 2019): Most of the api is tested in the integrations/ tests.

GiteaMirror commented

2025-11-02 04:51:38 -06:00

@bclermont commented on GitHub (Mar 11, 2019):

ah thanks, I was looking into go-sdk for *_test.go files

@bclermont commented on GitHub (Mar 11, 2019): ah thanks, I was looking into go-sdk for `*_test.go` files

GiteaMirror commented

2025-11-02 04:51:38 -06:00

@sapk commented on GitHub (Mar 20, 2019):

This would also be more logic because currently the api response are defined in go-sdk. This would help the swagger part to be more maintained and maybe provide a stable generated client in various coding language directly from the swagger api specs.

@sapk commented on GitHub (Mar 20, 2019): This would also be more logic because currently the api response are defined in go-sdk. This would help the swagger part to be more maintained and maybe provide a stable generated client in various coding language directly from the swagger api specs.

GiteaMirror commented

2025-11-02 04:51:39 -06:00

@lunny commented on GitHub (May 6, 2019):

Is move SDK to gitea main repo is a good idea? Maybe we could move all the structs on gitea main repo and sdk repository could dependent that sub package.

@lunny commented on GitHub (May 6, 2019): Is move SDK to gitea main repo is a good idea? Maybe we could move all the structs on gitea main repo and sdk repository could dependent that sub package.

GiteaMirror commented

2025-11-02 04:51:39 -06:00

@sapk commented on GitHub (May 6, 2019):

@lunny We can even move struct to main and generate the various sdk client from swagger.

@sapk commented on GitHub (May 6, 2019): @lunny We can even move struct to main and generate the various sdk client from swagger.

GiteaMirror commented

2025-11-02 04:51:39 -06:00

@techknowlogick commented on GitHub (May 6, 2019):

I think it is good for sdk to be in the main repo because we can use sub packages to keep things split up like they are, but still keep PRs manageable. As currently we have to ensure that we merge in sdk PRs before PRs in main repo, it'd be nice if we could just have one PR.

Edit: Just structs are fine too.

@techknowlogick commented on GitHub (May 6, 2019): I think it is good for sdk to be in the main repo because we can use sub packages to keep things split up like they are, but still keep PRs manageable. As currently we have to ensure that we merge in sdk PRs before PRs in main repo, it'd be nice if we could just have one PR. Edit: Just structs are fine too.

GiteaMirror commented

2025-11-02 04:51:39 -06:00

@lunny commented on GitHub (May 7, 2019):

@techknowlogick yeah, just structs then most time, we don't have to send two PRs to two repo. And SDK could follow some reversion of the structs sub package in go mod to keep compatible.

@lunny commented on GitHub (May 7, 2019): @techknowlogick yeah, just structs then most time, we don't have to send two PRs to two repo. And SDK could follow some reversion of the structs sub package in go mod to keep compatible.

GiteaMirror referenced this issue

2025-11-02 12:15:10 -06:00

[PR #2856] [MERGED] Add reactions to issues/PR and comments #16635

GiteaMirror referenced this issue

2025-11-02 12:18:23 -06:00

[PR #3083] [MERGED] Tests for reactions #16756

Sign in to join this conversation.