Skip to content

Conversation

lunny
Copy link
Member

@lunny lunny commented Mar 16, 2025

Move HasWiki out of the models package to avoid referencing the absolute wiki path directly.

@lunny lunny added the type/refactoring Existing code has been cleaned up. There should be no new functionality. label Mar 16, 2025
@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Mar 16, 2025
@github-actions github-actions bot added the modifies/go Pull requests that update Go code label Mar 16, 2025
Copy link
Contributor

@wxiaoguang wxiaoguang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should stop here.

The design is wrong.

You can't make every function do "for repo" and "for wiki".

Since wiki is also a git repo, it should share the same repo interface as a code repo.

@GiteaBot GiteaBot added lgtm/blocked A maintainer has reservations with the PR and thus it cannot be merged and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Mar 17, 2025
@wxiaoguang wxiaoguang dismissed their stale review March 27, 2025 07:33

dismiss

@GiteaBot GiteaBot added lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. and removed lgtm/blocked A maintainer has reservations with the PR and thus it cannot be merged labels Mar 27, 2025
@lunny lunny changed the title Remove HasWiki method and use IsWikiRepositoryExist Remove HasWiki method and use IsRepositoryExist Mar 29, 2025
@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Apr 9, 2025
@lunny
Copy link
Member Author

lunny commented Jun 18, 2025

last call @go-gitea/technical-oversight-committee

@wxiaoguang
Copy link
Contributor

Is it possible to have a better design to avoid filling the code base with a lot of if err != nil { return err }? This simple PR +119 −44, in the future there will be more if err != nil { return err } and does it make code more readable or maintainable?

@lunny
Copy link
Member Author

lunny commented Jun 19, 2025

Maybe we have two options. One is to store the presence of the wiki in the repo_unit table and retrieve the information from the database each time. The other is to creating a HasWiki function under services/wiki, handle the error internally within this function, and return the result accordingly.

@wxiaoguang
Copy link
Contributor

And I believe we should introduce a better error handling framework.

image

@wxiaoguang
Copy link
Contributor

For this PR, I do not see why Remove HasWiki method makes sense or brings benefit.

I do not see any feasible plan for the "git repo" related refactoring work.

@lunny
Copy link
Member Author

lunny commented Jun 19, 2025

For this PR, I do not see why Remove HasWiki method makes sense or brings benefit.

I do not see any feasible plan for the "git repo" related refactoring work.

This PR will try to make all other packages just depend on the relative path of the repository except gitrepo package. Now the absolute repository path will be used everywhere which will prevent abstract of repository storage.

@wxiaoguang
Copy link
Contributor

I have been tired of your infeasible plans, buggy code and stale PRs. So don't ask me to review.

@wxiaoguang
Copy link
Contributor

And, what is #29073, are we living in parallel universes ........

image image

@lunny
Copy link
Member Author

lunny commented Aug 25, 2025

And, what is #29073, are we living in parallel universes ........

image image

Sorry, it's #29033

@GiteaBot GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Aug 28, 2025
@wxiaoguang
Copy link
Contributor

And I believe we should introduce a better error handling framework.

@6543 I see you down-voted my proposal.

I don't know how many PRs you have reviewed or helped to improved. For me, the abused errors still occurs today, for example: #31262 (review), #31262 (review).

If you don't spend time on helping improving PRs or aren't able to propose a correct framework to resolve these low-level mistakes, I think you can just follow my plan.

@6543
Copy link
Member

6543 commented Aug 29, 2025

yes but thats off toppic to this specific pull here.

i personally realy dislice to use panic and catch them later somewhere and prevere to handle them more explizite. golang allows to ignore that concept easily and otherwhise you have the mentioned boilerplate witch i do understand is not nice either.

if somebody has a good proposal i wont downvote etc ... but can we discust this not here ... thats the two reasons i downfoted this instead of just leaving it ...

(als offtopic comment)

@wxiaoguang
Copy link
Contributor

wxiaoguang commented Aug 29, 2025

  1. It is not off-topic. This PR bloats a lot of new code with error checks. And the first commits are just wrong. I just can't bare the dirty and incorrect code.
  2. "golang allows to ignore that concept easily". No. That's what I mentioned many times: use framework design to avoid low-level mistakes.

If you think it is off-topic, I opened a new one: New web framework design #35378

@@ -35,11 +35,3 @@ func TestRepository_WikiPath(t *testing.T) {
expected := filepath.Join(setting.RepoRootPath, "user2/repo1.wiki.git")
assert.Equal(t, expected, repo.WikiPath())
}

func TestRepository_HasWiki(t *testing.T) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved to repository service package

@lunny lunny changed the title Remove HasWiki method and use IsRepositoryExist Move HasWiki to repository service package Aug 30, 2025
@lunny
Copy link
Member Author

lunny commented Aug 30, 2025

@6543 @wxiaoguang I pushed a new commit to reduce the error check.

@lunny lunny added the reviewed/wait-merge This pull request is part of the merge queue. It will be merged soon. label Sep 1, 2025
@lunny lunny added this to the 1.25.0 milestone Sep 1, 2025
@lunny lunny merged commit 4e1b8db into go-gitea:main Sep 1, 2025
26 checks passed
@lunny lunny deleted the lunny/move_wikipath branch September 1, 2025 18:13
@GiteaBot GiteaBot removed the reviewed/wait-merge This pull request is part of the merge queue. It will be merged soon. label Sep 1, 2025
hiifong added a commit to hiifong/gitea that referenced this pull request Sep 2, 2025
* main:
  [skip ci] Updated translations via Crowdin
  Use github.com/mholt/archives replace github.com/mholt/archiver (go-gitea#35390)
  Move some functions from package git to gitrepo (go-gitea#33910)
  Move git config/remote to gitrepo package and add global lock to resolve possible conflict when updating repository git config file (go-gitea#35151)
  Move HasWiki to repository service package (go-gitea#33912)
  Rename UpdateBranch API to RenameBranch API (go-gitea#35374)
zjjhot added a commit to zjjhot/gitea that referenced this pull request Sep 2, 2025
* giteaofficial/main:
  [skip ci] Updated translations via Crowdin
  Use github.com/mholt/archives replace github.com/mholt/archiver (go-gitea#35390)
  Move some functions from package git to gitrepo (go-gitea#33910)
  Move git config/remote to gitrepo package and add global lock to resolve possible conflict when updating repository git config file (go-gitea#35151)
  Move HasWiki to repository service package (go-gitea#33912)
  Rename UpdateBranch API to RenameBranch API (go-gitea#35374)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. modifies/go Pull requests that update Go code type/refactoring Existing code has been cleaned up. There should be no new functionality.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants