In Git 2.38, the `merge-tree` command introduced the `--write-tree`
option, which works directly on bare repositories. In Git 2.40, a new parameter `--merge-base` introduced so we require Git 2.40 to use the merge tree feature.
This option produces the merged tree object ID, allowing us to perform
diffs between commits without creating a temporary repository. By
avoiding the overhead of setting up and tearing down temporary repos,
this approach delivers a notable performance improvement.
It also fixes a possible situation that conflict files might be empty
but it's a conflict status according to
https://git-scm.com/docs/git-merge-tree#_mistakes_to_avoid
Replace #35542
---------
Signed-off-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Most potential deadlock problems should have been fixed, and new code is
unlikely to cause new problems with the new design.
Also raise the minimum Git version required to 2.6.0 (released in 2015)
Maybe fix#32018
- Use `gitrepo.GetMergeBase` method instead of other two
implementations.
- Add `FetchRemoteCommit` so that we don't need to add many `remote` to
the git repository to avoid possible git lock conflicts. A lock will
start when invoke the function, it will be invoked when cross-repository
comparing. The head repository will fetch the base repository's base
commit id. In most situations, it should lock the fork repositories so
that it should not become a bottleneck.
- Improve `GetCompareInfo` to remove unnecessarily adding remote.
- Remove unnecessary parameters of `SignMerge`.
1 Move `IsRepositoryModelOrDirExist` and `CheckCreateRepository` to
service layer
2 Use `gitrepo.Pushxxx` instead of `git.Push` when possible
3 use `gitrepo.Clonexxx` instead of `gitrepo.Clone` when possible
Partially fix#34710
The bug described in #34710 can be divided into two parts: `push.paths`
and `pull_request.paths`. This PR fixes the issue related to
`pull_request.paths`. The root cause is that the check for whether the
workflow can be triggered happens **before** updating the PR’s merge
base. This causes the file-change detection to use the old merge base.
Therefore, we need to update the merge base first and then check whether
the workflow can be triggered.
Permission & protection check:
- Fix Delete Release permission check
- Fix Update Pull Request with rebase branch protection check
- Fix Issue Dependency permission check
- Fix Delete Comment History ID check
Information leaking:
- Show unified message for non-existing user and invalid password
- Fix#35984
- Don't expose release draft to non-writer users.
- Make API returns signature's email address instead of the user
profile's.
Auth & Login:
- Avoid GCM OAuth2 attempt when OAuth2 is disabled
- Fix#35510
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Before this PR, when merging an empty PR with squash style will result
in 500.
---------
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Zettat123 <zettat123@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
`GITEA_PR_ID` is already part of the env variables available in the
githooks, but it contains a database ID instead of commonly used index
that is part of `owner/repo!index`
Fixes#32257
/claim #32257
Implemented commenting on unchanged lines in Pull Request diffs, lines
are accessed by expanding the diff preview. Comments also appear in the
"Files Changed" tab on the unchanged lines where they were placed.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This PR moved the creation of pushing comments before pull request
mergeable checking. So that when the pull request status changed, the
comments should have been created.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
To prevent potential bugs, the logic in #35543 makes `gitcmd.Command`
panic when attempting to override stdout or stderr. Instead of using
`PrepareCmd`, this PR now uses the WithXXX methods directly to avoid the
panic.
Fix#35603
Refactor Git command functions to use WithXXX methods instead of
exposing RunOpts.
This change simplifies reuse across gitrepo and improves consistency,
encapsulation, and maintainability of command options.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Partially fix#32018
`git config` and `git remote` write operations create a temporary file
named `config.lock`. Since these operations are not atomic, they must
not be run in parallel. If two requests attempt to modify the same
repository concurrently—such as during a compare operation—one may fail
due to the presence of an existing `config.lock` file.
In cases where `config.lock` is left behind due to an unexpected program
exit, a global lock mechanism could allow us to safely remove the stale
lock file when a related error is detected. While this behavior is not
yet implemented in this PR, it is planned for a future enhancement.
---------
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fix#34504
Since one required context can match more than one commit statuses, we
should not directly compare the lengths of `requiredCommitStatuses` and
`requiredContexts`
---------
Signed-off-by: Zettat123 <zettat123@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Signed SSH commits can look in the UI like on GitHub, just like gpg keys today in Gitea
* SSH format can be added in gitea config
* SSH Signing worked before with DEFAULT_TRUST_MODEL=committer
`TRUSTED_SSH_KEYS` can be a list of additional ssh public key contents
to trust for every user of this instance
Closes#34329
Related #31392
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Extract from #34531
## Move Commit status state to a standalone package
Move the state from `structs` to `commitstatus` package. It also
introduce `CommitStatusStates` so that the combine function could be
used from UI and API logic.
## Combined commit status Changed
This PR will follow Github's combined commit status. Before this PR,
every commit status could be a combined one.
According to
https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#get-the-combined-status-for-a-specific-reference
> Additionally, a combined state is returned. The state is one of:
> failure if any of the contexts report as error or failure
> pending if there are no statuses or a context is pending
> success if the latest status for all contexts is success
This PR will follow that rule and remove the `NoBetterThan` logic. This
also fixes the inconsistent between UI and API. In the API convert
package, it has implemented this which is different from the UI. It also
fixed the missing `URL` and `CommitURL` in the API.
## `CalcCommitStatus` return nil if there is no commit statuses
The behavior of `CalcCommitStatus` is changed. If the parameter commit
statuses is empty, it will return nil. The reference places should check
the returned value themselves.
If user leaves the page, the context will become cancelled, so that the
update process maybe terminal in an unexpected status. This PR haven't
resolve the problem totally. It uses a background context to not cancel
the update process even if the user leaved the pull request view page.
Fix#31779
`GetIssuesLastCommitStatus` will revoke `GetIssuesAllCommitStatus` but
it has been invoked. The `CommitStatus` template variable has never been
used in notification subscription page so that it could be removed.
Lunny Xiao
wxiaoguang
TheFox0x7
Zettat123
Daniel Mach
Kemal Zebari
Bryan Mutai
silverwind
ChristopherHX