aboutsummaryrefslogtreecommitdiffstats
path: root/services/pull
Commit message (Collapse)AuthorAgeFilesLines
* Retarget depending pulls when the parent branch is deleted (#28686)Viktor Kuzmin2024-01-171-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes you need to work on a feature which depends on another (unmerged) feature. In this case, you may create a PR based on that feature instead of the main branch. Currently, such PRs will be closed without the possibility to reopen in case the parent feature is merged and its branch is deleted. Automatic target branch change make life a lot easier in such cases. Github and Bitbucket behave in such way. Example: $PR_1$: main <- feature1 $PR_2$: feature1 <- feature2 Currently, merging $PR_1$ and deleting its branch leads to $PR_2$ being closed without the possibility to reopen. This is both annoying and loses the review history when you open a new PR. With this change, $PR_2$ will change its target branch to main ($PR_2$: main <- feature2) after $PR_1$ has been merged and its branch has been deleted. This behavior is enabled by default but can be disabled. For security reasons, this target branch change will not be executed when merging PRs targeting another repo. Fixes #27062 Fixes #18408 --------- Co-authored-by: Denys Konovalov <kontakt@denyskon.de> Co-authored-by: delvh <dev.lh@web.de>
* Concatenate error in `checkIfPRContentChanged` (#28731)Earl Warren2024-01-091-0/+4
| | | | | | | | | - If there's a error with the Git command in `checkIfPRContentChanged` the stderr wasn't concatendated to the error, which results in still not knowing why an error happend. - Adds concatenation for stderr to the returned error. - Ref: https://codeberg.org/forgejo/forgejo/issues/2077 Co-authored-by: Gusted <postmaster@gusted.xyz>
* Improve ObjectFormat interface (#28496)Lunny Xiao2023-12-191-5/+3
| | | | | | | | | | | | | | | | | | | | | | | The 4 functions are duplicated, especially as interface methods. I think we just need to keep `MustID` the only one and remove other 3. ``` MustID(b []byte) ObjectID MustIDFromString(s string) ObjectID NewID(b []byte) (ObjectID, error) NewIDFromString(s string) (ObjectID, error) ``` Introduced the new interfrace method `ComputeHash` which will replace the interface `HasherInterface`. Now we don't need to keep two interfaces. Reintroduced `git.NewIDFromString` and `git.MustIDFromString`. The new function will detect the hash length to decide which objectformat of it. If it's 40, then it's SHA1. If it's 64, then it's SHA256. This will be right if the commitID is a full one. So the parameter should be always a full commit id. @AdamMajer Please review.
* Adjust object format interface (#28469)Lunny Xiao2023-12-172-8/+3
| | | | | | | - Remove `ObjectFormatID` - Remove function `ObjectFormatFromID`. - Use `Sha1ObjectFormat` directly but not a pointer because it's an empty struct. - Store `ObjectFormatName` in `repository` struct
* Abstract hash function usage (#28138)Adam Majer2023-12-135-14/+30
| | | | | | Refactor Hash interfaces and centralize hash function. This will allow easier introduction of different hash function later on. This forms the "no-op" part of the SHA256 enablement patch.
* Remove GetByBean method because sometimes it's danger when query condition ↵Lunny Xiao2023-12-071-3/+1
| | | | | | | | | | | | | | | | | | | | parameter is zero and also introduce new generic methods (#28220) The function `GetByBean` has an obvious defect that when the fields are empty values, it will be ignored. Then users will get a wrong result which is possibly used to make a security problem. To avoid the possibility, this PR removed function `GetByBean` and all references. And some new generic functions have been introduced to be used. The recommand usage like below. ```go // if query an object according id obj, err := db.GetByID[Object](ctx, id) // query with other conditions obj, err := db.Get[Object](ctx, builder.Eq{"a": a, "b":b}) ```
* Use db.Find instead of writing methods for every object (#28084)Lunny Xiao2023-11-241-3/+3
| | | | For those simple objects, it's unnecessary to write the find and count methods again and again.
* Fix poster is not loaded in get default merge message (#27657)Lunny Xiao2023-10-171-0/+3
|
* Final round of `db.DefaultContext` refactor (#27587)JakobDev2023-10-143-9/+9
| | | Last part of #27065
* Replace assert.Fail with assert.FailNow (#27578)Nanguan Lin2023-10-111-1/+1
| | | | | | | | | assert.Fail() will continue to execute the code while assert.FailNow() not. I thought those uses of assert.Fail() should exit immediately. PS: perhaps it's a good idea to use [require](https://pkg.go.dev/github.com/stretchr/testify/require) somewhere because the assert package's default behavior does not exit when an error occurs, which makes it difficult to find the root error reason.
* Penultimate round of `db.DefaultContext` refactor (#27414)JakobDev2023-10-112-3/+3
| | | | | | | Part of #27065 --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Remove redundant `len` check around loop (#27464)Eng Zer Jun2023-10-061-7/+5
| | | | | | | | | | | | | | | | | | | | This pull request is a minor code cleanup. From the Go specification (https://go.dev/ref/spec#For_range): > "1. For a nil slice, the number of iterations is 0." > "3. If the map is nil, the number of iterations is 0." `len` returns 0 if the slice or map is nil (https://pkg.go.dev/builtin#len). Therefore, checking `len(v) > 0` before a loop is unnecessary. --- At the time of writing this pull request, there wasn't a lint rule that catches these issues. The closest I could find is https://staticcheck.dev/docs/checks/#S103 Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
* Even more `db.DefaultContext` refactor (#27352)JakobDev2023-10-031-1/+1
| | | | | | | | Part of #27065 --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: delvh <dev.lh@web.de>
* More `db.DefaultContext` refactor (#27265)JakobDev2023-09-292-4/+4
| | | | | | | Part of #27065 This PR touches functions used in templates. As templates are not static typed, errors are harder to find, but I hope I catch it all. I think some tests from other persons do not hurt.
* make writing main test easier (#27270)Lunny Xiao2023-09-281-4/+1
| | | | | | | | | This PR removed `unittest.MainTest` the second parameter `TestOptions.GiteaRoot`. Now it detects the root directory by current working directory. --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* More refactoring of `db.DefaultContext` (#27083)JakobDev2023-09-151-1/+1
| | | Next step of #27065
* move repository deletion to service layer (#26948)Lunny Xiao2023-09-081-0/+2
| | | Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Move notification interface to services layer (#26915)Lunny Xiao2023-09-054-19/+19
| | | Extract from #22266
* Reduce some allocations in type conversion (#26772)Chongyi Zheng2023-08-291-2/+2
|
* Fix bug for ctx usage (#26762)Lunny Xiao2023-08-281-2/+2
| | | | | Regression from #26158 Fix #26684
* Add transaction when creating pull request created dirty data (#26259)Lunny Xiao2023-08-102-54/+86
| | | | | | | | | | | | Fix #26129 Replace #26258 This PR will introduce a transaction on creating pull request so that if some step failed, it will rollback totally. And there will be no dirty pull request exist. --------- Co-authored-by: Giteabot <teabot@gitea.io>
* Delete `issue_service.CreateComment` (#26298)caicandong2023-08-043-8/+6
| | | | | | | I noticed that `issue_service.CreateComment` adds transaction operations on `issues_model.CreateComment`, we can merge the two functions and we can avoid calling each other's methods in the `services` layer. Co-authored-by: Giteabot <teabot@gitea.io>
* Fix pull request check list is limited (#26179)caicandong2023-07-312-2/+2
| | | | | | | | | | | | In the original implementation, we can only get the first 30 records of the commit status (the default paging size), if the commit status is more than 30, it will lead to the bug #25990. I made the following two changes. - On the page, use the ` db.ListOptions{ListAll: true}` parameter instead of `db.ListOptions{}` - The `GetLatestCommitStatus` function makes a determination as to whether or not a pager is being used. fixed #25990
* Add commits dropdown in PR files view and allow commit by commit review (#25528)sebastian-sauer2023-07-281-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This PR adds a new dropdown to select a commit or a commit range (shift-click like github) of a Pull Request. After selection of a commit only the changes of this commit will be shown. When selecting a range of commits the diff of this range is shown. This allows to review a PR commit by commit or by viewing only commit ranges. The "Show changes since your last review" mechanism github uses is implemented, too. When reviewing a single commit or a commit range the "Viewed" functionality is disabled. ## Screenshots ### The commit dropdown ![image](https://github.com/go-gitea/gitea/assets/51889757/0db3ae62-1272-436c-be64-4730c5d611e3) ### Selecting a commit range ![image](https://github.com/go-gitea/gitea/assets/51889757/ad81eedb-8437-42b0-8073-2d940c25fe8f) ### Show changes of a single commit only ![image](https://github.com/go-gitea/gitea/assets/51889757/6b1a113b-73ef-4ecc-adf6-bc2340bb8f97) ### Show changes of a commit range ![image](https://github.com/go-gitea/gitea/assets/51889757/6401b358-cd66-4c09-8baa-6cf6177f23a7) Fixes https://github.com/go-gitea/gitea/issues/20989 Fixes https://github.com/go-gitea/gitea/issues/19263 --------- Co-authored-by: silverwind <me@silverwind.io> Co-authored-by: KN4CK3R <admin@oldschoolhack.me> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> Co-authored-by: delvh <dev.lh@web.de>
* Add context parameter to some database functions (#26055)Lunny Xiao2023-07-224-34/+31
| | | | | To avoid deadlock problem, almost database related functions should be have ctx as the first parameter. This PR do a refactor for some of these functions.
* Fix bug when pushing to a pull request which enabled dismiss approval ↵Lunny Xiao2023-07-202-6/+60
| | | | | | | | | | | | | | | automatically (#25882) Fix #25858 The option `dissmiss stale approvals` was listed on protected branch but never implemented. This PR fixes that. <img width="1006" alt="图片" src="https://github.com/go-gitea/gitea/assets/81045/60bfa968-4db7-4c24-b8be-2e5978f91bb9"> <img width="1021" alt="图片" src="https://github.com/go-gitea/gitea/assets/81045/8dabc14d-2dfe-40c2-94ed-24fcbf6e0e8f">
* Avoid amending the Rebase and Fast-forward merge if there is no message ↵wxiaoguang2023-07-101-0/+5
| | | | | | | | | | | | template (#25779) Related #22669. Close #25177 After the fix: ![image](https://github.com/go-gitea/gitea/assets/2114189/0e900927-ea72-4f8f-bde6-5ed927cb02f4) Co-authored-by: Giteabot <teabot@gitea.io>
* Less naked returns (#25713)65432023-07-071-10/+10
| | | | | just a step towards #25655 and some related refactoring
* Sync branches into databases (#22743)Lunny Xiao2023-06-293-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Related #14180 Related #25233 Related #22639 Close #19786 Related #12763 This PR will change all the branches retrieve method from reading git data to read database to reduce git read operations. - [x] Sync git branches information into database when push git data - [x] Create a new table `Branch`, merge some columns of `DeletedBranch` into `Branch` table and drop the table `DeletedBranch`. - [x] Read `Branch` table when visit `code` -> `branch` page - [x] Read `Branch` table when list branch names in `code` page dropdown - [x] Read `Branch` table when list git ref compare page - [x] Provide a button in admin page to manually sync all branches. - [x] Sync branches if repository is not empty but database branches are empty when visiting pages with branches list - [x] Use `commit_time desc` as the default FindBranch order by to keep consistent as before and deleted branches will be always at the end. --------- Co-authored-by: Jason Song <i@wolfogre.com>
* Add codeowners feature (#24910)Vladimir Buyanov2023-06-081-0/+7
| | | | | | Hello. This PR adds a github like configuration for the CODEOWNERS file. Resolves: #10161
* Improve queue and logger context (#24924)wxiaoguang2023-05-262-17/+7
| | | | | | | | | | | | | | | | | | | | | | | | Before there was a "graceful function": RunWithShutdownFns, it's mainly for some modules which doesn't support context. The old queue system doesn't work well with context, so the old queues need it. After the queue refactoring, the new queue works with context well, so, use Golang context as much as possible, the `RunWithShutdownFns` could be removed (replaced by RunWithCancel for context cancel mechanism), the related code could be simplified. This PR also fixes some legacy queue-init problems, eg: * typo : archiver: "unable to create codes indexer queue" => "unable to create repo-archive queue" * no nil check for failed queues, which causes unfriendly panic After this PR, many goroutines could have better display name: ![image](https://github.com/go-gitea/gitea/assets/2114189/701b2a9b-8065-4137-aeaa-0bda2b34604a) ![image](https://github.com/go-gitea/gitea/assets/2114189/f1d5f50f-0534-40f0-b0be-f2c9daa5fe92)
* Merge message template support for rebase without merge commit (#22669)Brecht Van Lommel2023-05-222-21/+99
| | | | | | | | | | | | Use `default_merge_message/REBASE_TEMPLATE.md` for amending the message of the last commit in the list of commits that was merged. Previously this template was mentioned in the documentation but not actually used. In this template additional variables `CommitTitle` and `CommitBody` are available, for the title and body of the commit. Ideally the message of every commit would be updated using the template, but doing an interactive rebase or merging commits one by one is complicated, so that is left as a future improvement.
* Support for status check pattern (#24633)Zettat1232023-05-171-22/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This PR is to allow users to specify status checks by patterns. Users can enter patterns in the "Status Check Pattern" `textarea` to match status checks and each line specifies a pattern. If "Status Check" is enabled, patterns cannot be empty and user must enter at least one pattern. Users will no longer be able to choose status checks from the table. But a __*`Matched`*__ mark will be added to the matched checks to help users enter patterns. Benefits: - Even if no status checks have been completed, users can specify necessary status checks in advance. - More flexible. Users can specify a series of status checks by one pattern. Before: ![image](https://github.com/go-gitea/gitea/assets/15528715/635738ad-580c-49cd-941d-c721e5b99be4) After: ![image](https://github.com/go-gitea/gitea/assets/15528715/16aa7b1b-abf1-4170-9bfa-ae6fc9803a82) --------- Co-authored-by: silverwind <me@silverwind.io>
* Rewrite queue (#24505)wxiaoguang2023-05-082-38/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | # ⚠️ Breaking Many deprecated queue config options are removed (actually, they should have been removed in 1.18/1.19). If you see the fatal message when starting Gitea: "Please update your app.ini to remove deprecated config options", please follow the error messages to remove these options from your app.ini. Example: ``` 2023/05/06 19:39:22 [E] Removed queue option: `[indexer].ISSUE_INDEXER_QUEUE_TYPE`. Use new options in `[queue.issue_indexer]` 2023/05/06 19:39:22 [E] Removed queue option: `[indexer].UPDATE_BUFFER_LEN`. Use new options in `[queue.issue_indexer]` 2023/05/06 19:39:22 [F] Please update your app.ini to remove deprecated config options ``` Many options in `[queue]` are are dropped, including: `WRAP_IF_NECESSARY`, `MAX_ATTEMPTS`, `TIMEOUT`, `WORKERS`, `BLOCK_TIMEOUT`, `BOOST_TIMEOUT`, `BOOST_WORKERS`, they can be removed from app.ini. # The problem The old queue package has some legacy problems: * complexity: I doubt few people could tell how it works. * maintainability: Too many channels and mutex/cond are mixed together, too many different structs/interfaces depends each other. * stability: due to the complexity & maintainability, sometimes there are strange bugs and difficult to debug, and some code doesn't have test (indeed some code is difficult to test because a lot of things are mixed together). * general applicability: although it is called "queue", its behavior is not a well-known queue. * scalability: it doesn't seem easy to make it work with a cluster without breaking its behaviors. It came from some very old code to "avoid breaking", however, its technical debt is too heavy now. It's a good time to introduce a better "queue" package. # The new queue package It keeps using old config and concept as much as possible. * It only contains two major kinds of concepts: * The "base queue": channel, levelqueue, redis * They have the same abstraction, the same interface, and they are tested by the same testing code. * The "WokerPoolQueue", it uses the "base queue" to provide "worker pool" function, calls the "handler" to process the data in the base queue. * The new code doesn't do "PushBack" * Think about a queue with many workers, the "PushBack" can't guarantee the order for re-queued unhandled items, so in new code it just does "normal push" * The new code doesn't do "pause/resume" * The "pause/resume" was designed to handle some handler's failure: eg: document indexer (elasticsearch) is down * If a queue is paused for long time, either the producers blocks or the new items are dropped. * The new code doesn't do such "pause/resume" trick, it's not a common queue's behavior and it doesn't help much. * If there are unhandled items, the "push" function just blocks for a few seconds and then re-queue them and retry. * The new code doesn't do "worker booster" * Gitea's queue's handlers are light functions, the cost is only the go-routine, so it doesn't make sense to "boost" them. * The new code only use "max worker number" to limit the concurrent workers. * The new "Push" never blocks forever * Instead of creating more and more blocking goroutines, return an error is more friendly to the server and to the end user. There are more details in code comments: eg: the "Flush" problem, the strange "code.index" hanging problem, the "immediate" queue problem. Almost ready for review. TODO: * [x] add some necessary comments during review * [x] add some more tests if necessary * [x] update documents and config options * [x] test max worker / active worker * [x] re-run the CI tasks to see whether any test is flaky * [x] improve the `handleOldLengthConfiguration` to provide more friendly messages * [x] fine tune default config values (eg: length?) ## Code coverage: ![image](https://user-images.githubusercontent.com/2114189/236620635-55576955-f95d-4810-b12f-879026a3afdf.png)
* Refresh the refernce of the closed PR when reopening (#24231)sillyguodong2023-05-081-11/+5
| | | | | | | | | | | | | | | | | | | | | | Close #24213 Replace #23830 #### Cause - Before, in order to making PR can get latest commit after reopening, the `ref`(${REPO_PATH}/refs/pull/${PR_INDEX}/head) of evrey closed PR will be updated when pushing commits to the `head branch` of the closed PR. #### Changes - For closed PR , won't perform these behavior: insert`comment`, push `notification` (UI and email), exectue [pushToBaseRepo](https://github.com/go-gitea/gitea/blob/74225033413dc0f2b308bbe069f6d185b551e364/services/pull/pull.go#L409) function and trigger `action` any more when pushing to the `head branch` of the closed PR. - Refresh the reference of the PR when reopening the closed PR (**even if the head branch has been deleted before**). Make the reference of PR consistent with the `head branch`.
* Make more functions use ctx instead of db.DefaultContext (#24068)wxiaoguang2023-04-143-6/+6
| | | | | | Continue the "ctx refactoring" work. There are still a lot db.DefaultContext, incorrect context could cause database deadlock errors.
* [Patch] Fix closed PR also triggers Webhooks and actions (#23782)sillyguodong2023-03-301-0/+4
| | | | | | Fix #23707 Cause by #23189 This PR is a quick fix that, when pushing commits to closed PR, webhook and actions also be triggered.
* Disable sending email after push a commit to a closed PR (#23462)sillyguodong2023-03-151-1/+4
| | | | | | | | | | | Close #23440 Cause by #23189 In #23189, we should insert a comment record into db when pushing a commit to the PR, even if the PR is closed. But should skip sending any notification in this case. --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Improve squash merge commit author and co-author with private emails (#22977)Brecht Van Lommel2023-03-092-7/+53
| | | | | | | | | | | | | When emails addresses are private, squash merges always use `@noreply.localhost` for the author of the squash commit. And the author is redundantly added as a co-author in the commit message. Also without private mails, the redundant co-author is possible when committing with a signature that's different than the user full name and primary email. Now try to find a commit by the same user in the list of commits, and prefer the signature from that over one constructed from the account settings.
* Fix pull request update showing too many commits with multiple branches (#22856)Brecht Van Lommel2023-03-091-78/+12
| | | | | | | | | | | | | | | When the base repository contains multiple branches with the same commits as the base branch, pull requests can show a long list of commits already in the base branch as having been added. What this is supposed to do is exclude commits already in the base branch. But the mechansim to do so assumed a commit only exists in a single branch. Now use `git rev-list A B --not branchName` instead of filtering commits afterwards. The logic to detect if there was a force push also was wrong for multiple branches. If the old commit existed in any branch in the base repository it would assume there was no force push. Instead check if the old commit is an ancestor of the new commit.
* Refactor merge/update git command calls (#23366)wxiaoguang2023-03-093-38/+28
| | | | | | | | | | | | | | | | Follow #22568 * Remove unnecessary ToTrustedCmdArgs calls * the FAQ in #22678 * Quote: When using ToTrustedCmdArgs, the code will be very complex (see the changes for examples). Then developers and reviewers can know that something might be unreasonable. * The `signArg` couldn't be empty, it's either `-S{keyID}` or `--no-gpg-sign`. * Use `signKeyID` instead, add comment "empty for no-sign, non-empty to sign" * 5-line code could be extracted to a common `NewGitCommandCommit()` to handle the `signKeyID`, but I think it's not a must, current code is clear enough.
* Refactor and tidy-up the merge/update branch code (#22568)zeripath2023-03-0711-606/+753
| | | | | | | | | | | | | | | | | | | The merge and update branch code was previously a little tangled and had some very long functions. The functions were not very clear in their reasoning and there were deficiencies in their logging and at least one bug in the handling of LFS for update by rebase. This PR substantially refactors this code and splits things out to into separate functions. It also attempts to tidy up the calls by wrapping things in "context"s. There are also attempts to improve logging when there are errors. Signed-off-by: Andrew Thornton <art27@cantab.net> --------- Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: delvh <dev.lh@web.de>
* Make Ctrl+Enter submit a pending comment (starting review) instead of ↵wxiaoguang2023-03-041-4/+4
| | | | | | | | | | | | | | | | | | submitting a single comment (#23245) Close #23241 Before: press Ctrl+Enter in the Code Review Form, a single comment will be added. After: press Ctrl+Enter in the Code Review Form, start the review with pending comments. The old name `is_review` is not clear, so the new code use `pending_review` as the new name. Co-authored-by: delvh <leon@kske.dev> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Fix cannot reopen after pushing commits to a closed PR (#23189)sillyguodong2023-03-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Close: #22784 1. On GH, we can reopen a PR which was closed before after pushing commits. After reopening PR, we can see the commits that were pushed after closing PR in the time line. So the case of [issue](https://github.com/go-gitea/gitea/issues/22784) is a bug which needs to be fixed. 2. After closing a PR and pushing commits, `headBranchSha` is not equal to `sha`(which is the last commit ID string of reference). If the judgement exists, the button of reopen will not display. So, skip the judgement if the status of PR is closed. ![image](https://user-images.githubusercontent.com/33891828/222037529-651fccf9-0bba-433e-b2f0-79c17e0cc812.png) 3. Even if PR is already close, we should still insert comment record into DB when we push commits. So we should still call function `CreatePushPullComment()`. https://github.com/go-gitea/gitea/blob/067b0c2664d127c552ccdfd264257caca4907a77/services/pull/pull.go#L260-L282 So, I add a switch(`includeClosed`) to the `GetUnmergedPullRequestsByHeadInfo` func to control whether the status of PR must be open. In this case, by setting `includeClosed` to `true`, we can query the closed PR. ![image](https://user-images.githubusercontent.com/33891828/222621045-bb80987c-10c5-4eac-aa0c-1fb9c6aefb51.png) 4. In the loop of comments, I use the`latestCloseCommentID` variable to record the last occurrence of the close comment. In the go template, if the status of PR is closed, the comments whose type is `CommentTypePullRequestPush(29)` after `latestCloseCommentID` won't be rendered. ![image](https://user-images.githubusercontent.com/33891828/222058913-c91cf3e3-819b-40c5-8015-654b31eeccff.png) e.g. 1). The initial status of the PR is opened. ![image](https://user-images.githubusercontent.com/33891828/222453617-33c5093e-f712-4cd6-8489-9f87e2075869.png) 2). Then I click the button of `Close`. PR is closed now. ![image](https://user-images.githubusercontent.com/33891828/222453694-25c588a9-c121-4897-9ae5-0b13cf33d20b.png) 3). I try to push a commit to this PR, even though its current status is closed. ![image](https://user-images.githubusercontent.com/33891828/222453916-361678fb-7321-410d-9e37-5a26e8095638.png) But in comments list, this commit do not display.This is as expected ：） ![image](https://user-images.githubusercontent.com/33891828/222454169-7617a791-78d2-404e-be5e-77d555f93313.png) 4). Click the `Reopen` button, the commit which is pushed after closing PR display now. ![image](https://user-images.githubusercontent.com/33891828/222454533-897893b6-b96e-4701-b5cb-b1800f382b8f.png) --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Do not create commit graph for temporary repos (#23219)Brecht Van Lommel2023-03-011-2/+8
| | | | | | | When fetching remotes for conflict checking, skip unnecessary and potentially slow writing of commit graphs. In a test with the Blender repository, this reduces conflict checking time for one pull request from about 2s to 0.1s.
* Add force_merge to merge request and fix checking mergable (#23010)Jason Song2023-02-211-9/+28
| | | Fix #23000.
* Use `--message=%s` for git commit message (#23028)wxiaoguang2023-02-211-2/+2
| | | | | | | | | | | | | | | | | | | Close #23027 `git commit` message option _only_ supports 4 formats (well, only ....): * `"commit", "-m", msg` * `"commit", "-m{msg}"` (no space) * `"commit", "--message", msg` * `"commit", "--message={msg}"` The long format with `=` is the best choice, and it's documented in `man git-commit`: `-m <msg>, --message=<msg> ...` ps: I would suggest always use long format option for git command, as much as possible. Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Rename `repo.GetOwner` to `repo.LoadOwner` (#22967)yp053272023-02-183-11/+11
| | | | | | | Fixes https://github.com/go-gitea/gitea/issues/22963 --------- Co-authored-by: Yarden Shoham <hrsi88@gmail.com>
* Add context cache as a request level cache (#22294)Lunny Xiao2023-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To avoid duplicated load of the same data in an HTTP request, we can set a context cache to do that. i.e. Some pages may load a user from a database with the same id in different areas on the same page. But the code is hidden in two different deep logic. How should we share the user? As a result of this PR, now if both entry functions accept `context.Context` as the first parameter and we just need to refactor `GetUserByID` to reuse the user from the context cache. Then it will not be loaded twice on an HTTP request. But of course, sometimes we would like to reload an object from the database, that's why `RemoveContextData` is also exposed. The core context cache is here. It defines a new context ```go type cacheContext struct { ctx context.Context data map[any]map[any]any lock sync.RWMutex } var cacheContextKey = struct{}{} func WithCacheContext(ctx context.Context) context.Context { return context.WithValue(ctx, cacheContextKey, &cacheContext{ ctx: ctx, data: make(map[any]map[any]any), }) } ``` Then you can use the below 4 methods to read/write/del the data within the same context. ```go func GetContextData(ctx context.Context, tp, key any) any func SetContextData(ctx context.Context, tp, key, value any) func RemoveContextData(ctx context.Context, tp, key any) func GetWithContextCache[T any](ctx context.Context, cacheGroupKey string, cacheTargetID any, f func() (T, error)) (T, error) ``` Then let's take a look at how `system.GetString` implement it. ```go func GetSetting(ctx context.Context, key string) (string, error) { return cache.GetWithContextCache(ctx, contextCacheKey, key, func() (string, error) { return cache.GetString(genSettingCacheKey(key), func() (string, error) { res, err := GetSettingNoCache(ctx, key) if err != nil { return "", err } return res.SettingValue, nil }) }) } ``` First, it will check if context data include the setting object with the key. If not, it will query from the global cache which may be memory or a Redis cache. If not, it will get the object from the database. In the end, if the object gets from the global cache or database, it will be set into the context cache. An object stored in the context cache will only be destroyed after the context disappeared.
* Fix update by rebase being wrongly disabled by protected base branch (#22825)Brecht Van Lommel2023-02-091-1/+1
| | | | The branch this is force pushing to is the head branch in the head repo, so it should be checking if that is protected, not the base.
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-13 22:57:46 +0000