Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add searched repo type to api/repo/search #2321

Closed
Morlinest opened this issue Aug 17, 2017 · 5 comments
Closed

Add searched repo type to api/repo/search #2321

Morlinest opened this issue Aug 17, 2017 · 5 comments
Assignees
@Morlinest
Labels
type/enhancement An improvement of existing functionality
Milestone
1.3.0

Comments

@Morlinest
Copy link
Member

Morlinest commented Aug 17, 2017 •
edited
Loading

I want to add an option to look for a specific type of repo (fork, mirror, source, collaborative or all). I think there are two options how to search repositories:

  1. Search only 1 type - this means SearchRepoOptions will contain 1 attribute with one of possible values
  2. Search any combination of types at once - this means SearchRepoOptions will contains every possible option and result will be their mix (OR), for example mirror OR fork repositories

Any opinion? I've already done the first option, but second can be done very fast too.
@lunny
Copy link
Member

lunny commented Aug 17, 2017

I think one is enough.

@lunny lunny added the type/enhancement An improvement of existing functionality label Aug 17, 2017
@Morlinest
Copy link
Member Author

On first option I don't like the code (can be just bad because of my skills in GO and understanding this project code). I need new type RepoType, const for each type (like RepoTypeAll,RepoTypeFork, ...) and then 'map[string]RepoType' in handler to map query to this types. In second option, I can add each type directly to SearchRepoOptions as bools and use ifs in handler to set it. This is my "code" dilema :D

@lunny
Copy link
Member

lunny commented Aug 17, 2017

I like first option.

@Morlinest
Copy link
Member Author

@lunny OK :) Will send PR soon, you can assign this issue to me.

@Morlinest Morlinest mentioned this issue Aug 17, 2017
Closed
@lunny lunny added this to the 1.x.x milestone Aug 30, 2017
@Morlinest Morlinest mentioned this issue Oct 21, 2017
Merged
@Morlinest
Copy link
Member Author

Closed by #2756

@lunny lunny modified the milestones: 1.x.x, 1.3.0 Nov 5, 2017
@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
6543 pushed a commit to 6543-forks/gitea that referenced this issue Feb 26, 2024
@Gusted
[BUG] Fix pull request reopen conditions
f779aa7 
- Move the conditions code around, such that the existence of the head
and base is first checked (so a clear error can be given, instead of a
possible server error). This makes it easier to read this code. As the
logic is now grouped together.
- Adds integration testing that simulates the deletion of the base and
head branch and ensures the pull request cannot be opened. The 'normal'
testcase also 'informally' ensures that the previous incorrect condition
is not there, because the branch `base-branch` doesn't exist on the head
repository.
- Resolves go-gitea#2321
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@Morlinest Morlinest

Labels
type/enhancement An improvement of existing functionality
Projects
None yet
Milestone
1.3.0
Development

No branches or pull requests
2 participants
@lunny @Morlinest