Fix#33966
```
;; User must sign in to view anything.
;; It could be set to "expensive" to block anonymous users accessing some pages which consume a lot of resources,
;; for example: block anonymous AI crawlers from accessing repo code pages.
;; The "expensive" mode is experimental and subject to change.
;REQUIRE_SIGNIN_VIEW = false
```
The doctor storage check reconstructs the lfs oid by producing a string
where the path separator is stripped
ab/dc/efg -> abdcefg. Windows however uses a backslash and thus the
ReplaceAll call doesn't produce the correct oid resulting in all lfs
objects being classed as orphaned.
This PR allows this to be more OS agnostic.
Closes#34039
---------
Co-authored-by: Giteabot <teabot@gitea.io>
Follow #33127Fix#8649, fix#639
This is a complete solution. A repo unit could be set to:
* Anonymous read (non-signed-in user)
* Everyone read (signed-in user)
* Everyone write (wiki-only)
Follow #33127
This PR add backend logic and test for "anonymous access", it shares the
same logic as "everyone access", so not too much change.
By the way, split `SettingsPost` into small functions to make it easier
to make frontend-related changes in the future.
Next PR will add frontend support for "anonymous access"
* reuse recoverable error checks across mirror_pull
* add new cases for 'cannot lock ref/not our ref' (race condition in
fetch) and 'Unable to create/lock"
* move lfs sync right after commit graph write, and before other
maintenance which may fail
* try a prune for 'broken reference' as well as 'not our ref'
* always sync LFS right after commit graph write, and before other
maintenance which may fail
This handles a few cases where our very large and very active
repositories could serve mirrored git refs, but be missing lfs files:
## Case 1 (multiple variants): Race condition in git fetch
There was already a check for 'unable to resolve reference' on a failed
git fetch, after which a git prune and then subsequent fetch are
performed. This is to work around a race condition where the git remote
tells Gitea about a ref for some HEAD of a branch, then fails a few
seconds later because the remote branch was deleted, or the ref was
updated (force push).
There are two more variants to the error message you can get, but for
the same kind of race condition. These *may* be related to the git
binary version Gitea has access to (in my case, it was 2.48.1).
## Case 2: githttp.go can serve updated git refs before it's synced lfs
oids
There is probably a more aggressive refactor we could do here to have
the cat-file loop use FETCH_HEAD instead of relying on the commit graphs
to be committed locally (and thus serveable to clients of Gitea), but a
simple reduction in the occurrences of this for me was to move the lfs
sync block immediately after the commit-graph write and before any other
time-consuming (or potentially erroring/exiting) blocks.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
1. Ignore empty inputs in `UnmarshalHandleDoubleEncode`
2. Ignore non-existing `stateEvent.User` in gitlab migration
3. Enable `release` and `wiki` units when they are selected in migration
4. Sanitize repo name for migration and new repo
The pagination on the user dashboard sounds unnecessary, this will
change it to a prev/next buttons. For instances with around `10 million`
records in the action table, this option affects how the user dashboard
is loaded on first visit.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Giteabot <teabot@gitea.io>
Two SQLs are very slow when `action` table have over 5M records.
```
database duration=1.8881s db.sql="SELECT created_unix DIV 900 * 900 AS timestamp, count(user_id) as contributions FROM `action` WHERE user_id=? AND act_user_id=? AND (created_unix > ?) GROUP BY timestamp ORDER BY timestamp"
database duration=1.5408s db.sql="SELECT count(*) FROM `action` WHERE (user_id = ?) AND (is_deleted = ?)"
```
This will cache the count for the first loading or when the activities
changed.
Resolve#29328
This pull request introduces a file tree on the left side when reviewing
files of a repository.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Extract from #28966
This PR uses `gitrepo.IsRepositoryExist` instead of `util.IsExist` to
detect whether the repository exist in disk. This will move `RepoPath`
detail behind of package `gitrepo` to make it easier to do possible
changes where storing the repositories.
No code change
Fix#33490
It will only read the changed file on the pushed commits but not all the
files of this PR.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fix#33358, fix#21970
This adds a step in the `GitDiffForRender` that does syntax highlighting for the
entire file and then only references lines from that syntax highlighted
code. This allows things like multi-line comments to be syntax
highlighted correctly.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
The diff stats are no longer part of the diff generation.
Use `GetDiffShortStat` instead to get the total number of changed files,
added lines, and deleted lines.
As such, `gitdiff.GetDiff` can be simplified:
It should not do more than expected.
And do not run "git diff --shortstat" for pull list. Fix#31492
This is a X-GitHub Header port
* repository for repository webhooks (matches GitHub)
* organization for organization webhooks (matches GitHub)
* user for user webhooks (Gitea specific)
* system for system webhooks (Gitea specific)
* default for default hooks needs testing (Gitea specific)
- `X-Gitea-Hook-Installation-Target-Type`
- `X-GitHub-Hook-Installation-Target-Type`
