Backport #29859 by @buckybytes
The error message:
`editor.file_changed_while_editing = The file contents have changed
since you started editing. <a target="_blank" rel="noopener noreferrer"
href="%s">Click here</a> to see them or <strong>Commit Changes
again</strong> to overwrite them.`
Is re-used in inappropriate contexts. The link in the key goes to a 404
when the key is used in a situation where the file contents have not
changed.
Added two new keys to differentiate commit id mismatch and push out of
date conditions.
Co-authored-by: buckybytes <158571971+buckybytes@users.noreply.github.com>
(cherry picked from commit 00ea9af8e118790a186b4cf78a0ce85ce986bf1d)
Backport #29863 by @lng2020
Sometimes the column name is case-sensitive and it may cause 500.
Co-authored-by: Nanguan Lin <nanguanlin6@gmail.com>
(cherry picked from commit c044510ca8bed67cb2d50ba741b3d0b520aa3c43)
Backport #29813 by @yardenshoham
It didn't include the word picker.
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
(cherry picked from commit 47dc4598a305ea1e6017803b95c7c60d0be64784)
Backport #29732
This adds new lexers and includes some fixes. See
https://github.com/alecthomas/chroma/releases/tag/v2.13.0 for the full
changelog.
Co-authored-by: JakobDev <jakobdev@gmx.de>
(cherry picked from commit 31ab839a6587ea93edfec4d0147282c689d3e312)
Backport #29684 by @silverwind
Fixes: https://github.com/go-gitea/gitea/issues/29414
I see no way for us to catch this error, so downgrade it until
https://github.com/microsoft/monaco-editor/issues/4325 is fixed, which
will likely take a few weeks to propagate up from vscode.
The entries in `updates.config.js` will make
[`updates`](https://github.com/silverwind/updates) not upgrade these
anymore and I think it's good documentation as well to have the reasons
why we don't upgrade these dependencies.
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit 462ae88fc2e6295a9376855627ad2a824a6c8f1d)
- Backport of #2696
- Add `form-fetch-action` to indicate that this form POST to an link
that returns JSON and thus should be handled by Javascript code.
- Found by @fnetx
- Regression of https://codeberg.org/forgejo/forgejo/pulls/1793
(cherry picked from commit 9551c1a6f8)
Backport of #2658
Regression of #2507, which switched the HEAD from `pr.GetGitRefName()`
to `pr.HeadCommitID` but it had to be `prInfo.HeadCommitID`. Resolves #2656
I was able to reproduce this locally with _some_ pull requests, haven't
been able to get a reproducer trough integration testing.
(cherry picked from commit a4cc37b46a)
This should fix #2266.
This has apparently be fixed in `main` https://github.com/go-gitea/gitea/pull/27798 (but quite a big PR, which was not backported). I should likely push the test to the main branch as well.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2626
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
Backport #29305 by @DanielMatiasCarvalho
This seeks to fix the bug reported on issue #29196.
Cause:
ID's with custom characters (- , _ , etc.), were not linking correctly
in the Markdown file when rendered in the browser because the ID in the
respective destinies would be different than the one in anchor, while
for IDs with only letters, the ID would be the same.
Fix:
It was suggested that to fix this bug, it should more or less like
GitHub does it. While in gitea the anchors would be put in HTML like
this:
```
<p dir="auto"><a href="#user-content-_toc152597800" rel="nofollow">Review</a></p>
<p dir="auto"><a href="#user-content-_toc152597802" rel="nofollow">Staging</a></p>
<p dir="auto"><a href="#user-content-_toc152597803" rel="nofollow">Development</a></p>
<p dir="auto"><a href="#user-content-_toc152597828" rel="nofollow">Testing</a></p>
<p dir="auto"><a href="#user-content-_toc152597829" rel="nofollow">Unit-tests</a></p>
```
In GitHub, the same anchor's href properties would be the same without
"user-content-" trailing behind.
So my code made sure to change those anchors, so it would not include
"user-content-" and then add respective Event Listeners so it would
scroll into the supposed places.
Fixes: #29196
Co-authored-by: DC <106393991+DanielMatiasCarvalho@users.noreply.github.com>
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit bfc7c8a5985825ec28f3feefe1d050ec52525097)
Backport #29672 by @charles7668
Close #29661
fix #29656
Co-authored-by: charles <30816317+charles7668@users.noreply.github.com>
(cherry picked from commit 1f897637441a9a5c43e01b84e374d836d9260a00)
Backport #29554 by @lng2020
As title.
The former code directly used `ctx.Repo.GitRepo`, causing 500.
22b4f0c09f/routers/api/v1/repo/release.go (L241)
Co-authored-by: Nanguan Lin <nanguanlin6@gmail.com>
(cherry picked from commit b84303ef6e73e2436f0c4c3985020be6bbbb5d1e)
Backport #29430
Thanks to inferenceus : some sort orders on the "explore/users" page
could list users by their lastlogintime/updatetime.
It leaks user's activity unintentionally. This PR makes that page only
use "supported" sort orders.
Removing the "sort orders" could also be a good solution, while IMO at
the moment keeping the "create time" and "name" orders is also fine, in
case some users would like to find a target user in the search result,
the "sort order" might help.
(cherry picked from commit 2b059f493e46b8b0fb52492623e36a8375cb5fbb)
Backport #29537 by wxiaoguang
This is only a quick fix to make it easier to backport.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 971eab18fa0b29312105df739fba443cf9e84d50)
Backport #29532
Without `case <-t.C`, the workers would stop incorrectly, the test won't
pass. For the worse case, there might be only one running worker
processing the queue items for long time because other workers are
stopped. The root cause is related to the logic of doDispatchBatchToWorker.
It isn't a serious problem at the moment, so keep it as-is.
(cherry picked from commit 86cd94cba6d63c84528f6f8d52b1ec22b44ac2f8)
Backport #29531 by wxiaoguang
Add two "HTMLURL" methods for PackageDescriptor.
And rename "FullWebLink" to "VersionWebLink"
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 8723389028bcb5e96359fca61efd7d6da0d6af99)
Backport #29535 by wxiaoguang
* `$referenceUrl`: it is constructed by "Issue.Link", which already has
the "AppSubURL"
* `window.location.href`: AppSubURL could be empty string, so it needs
the trailing slash
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 401cc394d52c6126d3cbca1e1367c4e4da5110f9)
Backport #29407 by @silverwind
- `e.error` can be undefined in some cases which would raise an error
inside this error handler, fixed that.
- The displayed message mentions looking into the console, but in my
case of error from `ResizeObserver` there was nothing there, so add this
logging. I think this logging was once there but got lost during
refactoring.
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit 9abba8c11a2eddfa8da25946fdd43be8d0c53689)
Backport #29448 by @charles7668
issue : #28239
The counter number script uses the 'checkbox' attribute to determine
whether an item is selected or not.
However, the input event only increments the counter value, and when
more items are displayed, it does not update all previously loaded
items.
As a result, the display becomes incorrect because it triggers the
update counter script, but checkboxes that are selected without the
'checked' attribute are not counted
Co-authored-by: charles <30816317+charles7668@users.noreply.github.com>
(cherry picked from commit 5477728282de19b1638691b88449b1933ed5a4d8)
Backport #29470 by @silverwind
Ported the function as-is and added comments so we don't forget about
this in the future.
Fixes: https://github.com/go-gitea/gitea/issues/29462
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit 222f93822eb4d03f5001ef665377a115bc27ccb6)
Backport #29464 by @Zettat123
Fix #27906
According to GitHub's
[documentation](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds),
a job should always run when its `if` is `always()`
> If you would like a job to run even if a job it is dependent on did
not succeed, use the `always()` conditional expression in
`jobs.<job_id>.if`.
Co-authored-by: Zettat123 <zettat123@gmail.com>
(cherry picked from commit eabcfd3f7d9321fcf03e52977c178a96627a68da)
