Before this PR, the PR migration code populates Gitea's MergedCommitID
field by using GitLab's merge_commit_sha field. However, that field is
only populated when the PR was merged using a merge strategy. When a
squash strategy is used, squash_commit_sha is populated instead.
Given that Gitea does not keep track of merge and squash commits
separately, this PR simply populates Gitea's MergedCommitID by using
whichever field is present in the GitLab API response.
Some translations are duplicated for the same package fields; it should
be possible to use the same approach. Checked packages to use the same
forms in templates.
1. Removed repeated translations for the same fields
2. Linked template files to the same translation fields
3. Added repository site link for nuget packages
* Show checkout instructions also when there is no permission to push,
for anyone who wants to locally test the changes.
* First checkout the branch exactly as is, without immediately having to
solve merge conflicts. Leave this to the merge step, since it's often
convenient to test a change without worrying about this.
* Use `git fetch -u`, so an existing local branch is updated when
re-testing the same pull request. But not the more risky `git fetch -f`
in to handle force pushes, as we don't want to accidentally overwrite
important local changes.
* Show different merge command depending on the chosen merge style,
interactively updated.
See https://github.com/go-gitea/gitea/pull/27718#issuecomment-1773743014
. Add a test to ensure its behavior.
Why this test uses `ProjectBoardID=0`? Because in `SearchOptions`,
`ProjectBoardID=0` means what it is. But in `IssueOptions`,
`ProjectBoardID=0` means there is no condition, and
`ProjectBoardID=db.NoConditionID` means the board ID = 0.
It's really confusing. Probably it's better to separate the db search
engine and the other issue search code. It's really two different
systems. As far as I can see, `IssueOptions` is not necessary for most
of the code, which has very simple issue search conditions.
This PR will show the _noreply_ address in the privacy popup
_keep_email_private_popup_.
I had to look into the source code to figure out which E-Mail Adress I
had to use on gitea.com to hide it from public access.
According to the contribution guidelines I only updated the en-US
translation file.
Co-authored-by: Hakito <hakito@git.example.com>
## Add border to file tree 'sub-items'
close#24766
view in `gitea-light`
<img width="275" alt="image"
src="f1bf8736-2db3-454f-86f5-d050a2fae3eb">
view in `gitea-dark`
<img width="296" alt="image"
src="053e2e6e-28f7-41d2-a139-1dae4df45929">
## Change the 'item-file' padding
Before that the 'item-file' only have padding when they in
'item-directory', which is too compact when 'item-file' after
'item-directory'
<details>
---------
Co-authored-by: silverwind <me@silverwind.io>
When 0 or 1 files changed in a diff, we don't need to show a file tree.
This behaviour matches GitHub. Single-file diff after this change, note
absence of button:
<img width="1234" alt="image"
src="3618438b-e655-42a3-989f-f299267b2b8b">
Co-authored-by: Giteabot <teabot@gitea.io>
Before (almost no gap between files):
<img width="1240" alt="Screenshot 2023-10-24 at 19 43 32"
src="30cdbdbc-d102-479c-89ce-3f68837ae0cd">
After (with 8px gap):
<img width="1241" alt="Screenshot 2023-10-24 at 19 43 22"
src="72b26a30-8730-4a36-8de9-be143b684b98">
Hello there,
Cargo Index over HTTP is now prefered over git for package updates: we
should not force users who do not need the GIT repo to have the repo
created/updated on each publish (it can still be created in the packages
settings).
The current behavior when publishing is to check if the repo exist and
create it on the fly if not, then update it's content.
Cargo HTTP Index does not rely on the repo itself so this will be
useless for everyone not using the git protocol for cargo registry.
This PR only disable the creation on the fly of the repo when publishing
a crate.
This is linked to #26844 (error 500 when trying to publish a crate if
user is missing write access to the repo) because it's now optional.
---------
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
- The label HTML contained a quote that wasn't being closed.
Refs: https://codeberg.org/forgejo/forgejo/pulls/1651
(cherry picked from commit e2bc2c9a1fff482c49dbeb3a51e4e1c698bf506c)
Co-authored-by: Gusted <postmaster@gusted.xyz>
When hitting the `enter` key to create a new project column, the request
is sent twice because the `submit` event and `key up` event are both
triggered.
Probably a better solution is to rewrite these parts of the code to
avoid using native jQuery but reuse the `form-fetch-action` class. But
it's beyond my ability.
Per the discussion on #22054, the flow for adding a new team member to
an org is not intuitive for new Gitea users.
The ideal solution would be to add a new button on the Org > Members
index view (see the screenshot mockup in the issue description).
However, this would require a refactor of the UX for the flow. The
current flow has an implicit context of which team within the org the
new member is being added to ('Owners' by default). From the Members
index, there is no implicit context; the flow would have to add a picker
for which team the new member should be added to.
So, as a stopgap, this change simply adds a button to the Teams index
page that performs the same action as clicking on the title of the team
(a behavior that is currently too obscure as indicated in the comments
on the issue). This should reduce support burden and serve as a decent
temporary measure until the Add Member flow is refactored.
---------
Co-authored-by: tomholford <tomholford@users.noreply.github.com>
The current language stats are too obsessed with color matching. Similar
colors are always next to each other. It is a bit troublesome to find
the place where the color matching is generated, so just follow the
example of github and add a gap.
## before
<img width="883" alt="image"
src="cf54430c-616c-4b37-b561-5a37c20b2d94">
## after
<img width="877" alt="image"
src="e518ea36-2b8f-4f11-a867-a58dc393db85">
Fixes: https://github.com/go-gitea/gitea/issues/27604
Add negative margins so the header covers any shadow of active elements.
No rendering change of the content of the header because the padding
counteracts the effect.
<img width="128" alt="image"
src="3d0f55b6-9351-4985-a290-da9a92d15b4e">
1. remove unused function `MoveIssueAcrossProjectBoards`
2. extract the project board condition into a function
3. use db.NoCondition instead of -1. (BTW, the usage of db.NoCondition
is too confusing. Is there any way to avoid that?)
4. remove the unnecessary comment since the ctx refactor is completed.
5. Change `b.ID != 0` to `b.ID > 0`. It's more intuitive but I think
they're the same since board ID can't be negative.
TODOs:
- [x] write test for `GetIssueTotalTrackedTime`
- [x] frontport kitharas template changes and make them mobile-friendly
---
---
*Sponsored by Kithara Software GmbH*
If you set a checkbox as required in a issue form at the moment, the
checkbox is checked and read only, what does not make much sense. With
this PR, the Checkbox actually needs to be checked. The label supports
now also Markdown. This matches GitHub's behaviour.
And yes, I know the CSS is a ugly workaround. It looks like the given
CSS code is part Fomantic and I don't know how to change that. The
Maintainers are free to change that.
See [issue on
gitea.com](https://gitea.com/gitea/gitea-docusaurus/issues/38), copied
below for convenience:
> Hello, may I first confirm that the app.ini PROTOCOL config is case
sensitive (must be lowercase)?
>
> If so, I'd like to suggest for it to be highlighted in the [HTTPS
Setup](https://docs.gitea.com/administration/https-setup#using-the-built-in-server)
page.
> Perhaps something like:
> For the PROTOCOL=https field, make sure https is lowercase. Writing
PROTOCOL=HTTPS may result in a SSL_ERROR_RX_RECORD_TOO_LONG error on
Firefox or ERR_SSL_PROTOCOL_ERROR on Chrome and Edge.
>
> Background
> At first I carelessly wrote PROTOCOL=HTTPS in my app.ini, and Firefox
didn't allow me to connect because:
> Secure Connection Failed
> An error occurred during a connection to gitea.local.lan. SSL received
a record that exceeded the maximum permissible length.
> Error code: SSL_ERROR_RX_RECORD_TOO_LONG
> I spent maybe half an hour troubleshooting my certs, ports, and other
configs before backtracking to the start and realizing the
capitalization difference there 😅. When I changed that config to
lowercase, it worked.
For this PR I added the note in the Config Cheat Sheet page and fixed
the links to it from the HTTPS Setup page.
Was originally thinking to put the note in the HTTPS Setup page itself,
but since there are 2 sections referencing the PROTOCOL config, I was
thinking it'd be neater and more concise to put it in the Config Cheat
Sheet page instead. Especially since both sections already link to it,
and I actually tried to check that link quite early on in my
troubleshooting (but didn't pay much attention to it since the link was
broken).
## Before/After screenshots as per [this repo's
docs](https://github.com/go-gitea/gitea/tree/main/docs)
Before - links
Note: For this the links weren't broken, the links fix is because they
were broken on gitea.com's docs (see below).
After - links
Before - config cheat sheet
After - config cheat sheet
## Before/After screenshots as per [gitea.com's
docs](https://gitea.com/gitea/gitea-docusaurus)
Before - links
After - links
Before - config cheat sheet
After - config cheat sheet
this allows to deep link to the readme section of a repository.
fixes#27641
Screenshots:
No changes on initial display:
On hover the link is shown:
