Related to #30375.
It doesn't make sense to import `modules/web/middleware` and
`modules/setting` in `modules/web/session` since the last one is more
low-level.
And it looks like a workaround to call `DeleteLegacySiteCookie` in
`RegenerateSession`, so maybe we could reverse the importing by
registering hook functions.
(cherry picked from commit 61457cdf6b49225ae831fd9fb084deadd8bdb0fb)
Files in root were not linted, add them. No new violations.
(cherry picked from commit 354705450a410329d253023d2c66ef6d68ecc046)
Conflicts:
- CHANGELOG.md
Gitea specific, removed.
- Makefile
Adjusted SPELLCHECK_FILES: we don't need to filter the
CHANGELOG.md out. The conflict itself was resolved by manually
applying the change.
Fixes https://github.com/go-gitea/gitea/issues/28114 and behaviour
matches vscode on desktop as well.
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 49b80f8ac1cf9f0b56da0c73d0f34ef030f4c447)
Add some logic in `convert.ToBranchProtection` to return only the names
associated with readAccess instead of returning all names. This will
ensure consistency in behavior between the frontend and backend.
Fixes: #27694
---------
Co-authored-by: techknowlogick <techknowlogick@gitea.com>
Co-authored-by: wenzhuo.zhang <wenzhuo.zhang@geely.com>
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 02e183bf3fa502b7cef76e8dcdbf01b85ce641f0)
Fixes: https://github.com/go-gitea/gitea/issues/30512
I think this does mean those tools would run on a potential `vendor`
directory, but I'm not sure we really support vendoring of dependencies
anymore.
`release` has a `vendor` prerequisite so likely the source tarballs
contain vendor files?
(cherry picked from commit 8e12ef911a1d10dedb03e3127c42ca76f9850aca)
Conflicts:
- Makefile
Manually adjusted the changes.
Using the API, a user's _source_id_ can be set in the _CreateUserOption_
model, but the field is not returned in the _User_ model.
This PR updates the _User_ model to include the field _source_id_ (The
ID of the Authentication Source).
(cherry picked from commit 58b204b813cd3a97db904d889d552e64a7e398ff)
- Add new `Compare` struct to represent comparison between two commits
- Introduce new API endpoint `/compare/*` to get commit comparison
information
- Create new file `repo_compare.go` with the `Compare` struct definition
- Add new file `compare.go` in `routers/api/v1/repo` to handle
comparison logic
- Add new file `compare.go` in `routers/common` to define `CompareInfo`
struct
- Refactor `ParseCompareInfo` function to use `common.CompareInfo`
struct
- Update Swagger documentation to include the new API endpoint for
commit comparison
- Remove duplicate `CompareInfo` struct from
`routers/web/repo/compare.go`
- Adjust base path in Swagger template to be relative (`/api/v1`)
GitHub API
https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#compare-two-commits
---------
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
(cherry picked from commit c70e442ce4b99e2a1f1bf216afcfa1ad78d1925a)
Conflicts:
- routers/api/v1/swagger/repo.go
Conflict resolved by manually adding the lines from the Gitea
PR.
Small tweak here to prevent this and likely other events from
overflowing in the timeline:
<img width="895" alt="Screenshot 2024-04-14 at 22 53 17"
src="https://github.com/go-gitea/gitea/assets/115237/001b4f6b-f649-44ff-b2f0-c8e0dedeb384">
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 1508a85f6235814271ea927d651bcbcd8c9f5f18)
So it happened to me multiple times that air leaves zombie processes
after termination. I think ultimately it's some kind of bug in air, but
we can work around.
The change in the delay is unrelated to the zombie processes but seems
to help a bit with duplicate changes resulting in duplicate `make
generate` as seen here:
<img width="424" alt="Screenshot 2024-04-14 at 17 05 47"
src="https://github.com/go-gitea/gitea/assets/115237/6dd1d787-6be3-4fb2-8b0b-cd711c281793">
---------
Co-authored-by: delvh <dev.lh@web.de>
(cherry picked from commit 994920c677b04a720726d982e4d6212664b82a43)
---------
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit b84baf21fa19521e1ab303a60918c74f85fcad1c)
Conflicts:
- web_src/css/base.css
Trivial commit resolved by removing the conflicting part.
(it conflicted because we did not pick a previous PR)
Unify the behaviors of "user create" and "user change-password".
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit 4c6e2da088cf092a9790df5c84b7b338508fede7)
Conflicts:
- cmd/admin_user_create.go
Resolved by favoring Gitea's version of the conflicting areas.
- docs/content/administration/command-line.en-us.md
Removed, Gitea specific.
Added new class `flex-container-sidebar` to cover the dashboard sidebar.
Previously this was 37.5% with more padding. Now there is less empty
space between the two columns and this matches other pages like repo or
admin settings page.
Desktop:
<img width="1345" alt="Screenshot 2024-03-31 at 15 11 36"
src="https://github.com/go-gitea/gitea/assets/115237/717389d9-d42c-466e-a8fe-e968f79447fd">
Mobile:
<img width="444" alt="Screenshot 2024-03-31 at 15 11 44"
src="https://github.com/go-gitea/gitea/assets/115237/7faa840b-513a-411b-bf2d-26d52b9b71a0">
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 044cc169e75dccbf1d846f8774ef2feccd0da1fd)
It is possible to change some repo settings (its visibility, and
template status) via `git push` options: `-o repo.private=true`, `-o
repo.template=true`.
Previously, there weren't sufficient permission checks on these, and
anyone who could `git push` to a repository - including via an AGit
workflow! - was able to change either of these settings. To guard
against this, the pre-receive hook will now check if either of these
options are present, and if so, will perform additional permission
checks to ensure that these can only be set by a repository owner or
an administrator. Additionally, changing these settings is disabled for
forks, even for the fork's owner.
There's still a case where the owner of a repository can change the
visibility of it, and it will not propagate to forks (it propagates to
forks when changing the visibility via the API), but that's an
inconsistency, not a security issue.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Signed-off-by: Earl Warren <contact@earl-warren.org>
