| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove fork link closes all merge requests opened on source project
Currently, if you:
- create a fork
- open a merge request on the source project
- remove the fork link
The created MR cannot be closed.
With this MR, all pending MR is closed when the fork link is removed.
See merge request !3189
|
| | |\ |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
These methods are called quite often in loops so by memoizing their
output we can reduce timings a bit.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Fixes #14692
|
| | | | |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We have to ensure source_sha and target_sha are not nil before calling
Gitlab::Git::Commit.between.
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`MergeRequest#source_sha` is expected to return the sha of the source
branch last commit.
But when a open Merge Request has no diff (e.g. all commits have already
been merged to the target branch), `merge_request.source_sha`
incorrectly returns `nil`.
This was un-noticed before – but now that !2217 has been merged,
it makes `Gitlab::Git::Commit.between` raise an
"Unexpected nil argument" exception.
This fixes the crash, by making sure that `source_sha` returns a
correct result even when there is no diff available.
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
The OR condition for source_project_id/target_project_id leads to a
query plan that performs rather poorly on PostgreSQL due to the use of
sub-queries. Because Rails offers no easy alternative for this
particular problem we're forced to using a UNION for both conditions.
The resulting query performs much faster than just using an OR.
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | | |
Labels should be visible in dashboard and group milestone views
Closes #13621
See merge request !2931
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Make methods return ActiveRecord Relations instead of Arrays.
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Indicate when an MR diverged from the target branch
This adds an indicator to the "Merge MR" box, to tell if and how much an MR diverged from its target branch.
For instance, consider an MR to merge the branch `feature` into `master`. Some other commits were added to `master` since `feature` was created, and the two branches diverged.
```text
o master
|
o o feature
| |
o o
| /
o
```
In this case, there will be a label in the MR Merge box stating:
> This MR is by 3 commits behind the target branch `master`.
## Screenshots
### The branch diverged from the target (UI Proposal)
### The branch diverged from the target (alternative UI Proposal)
## How is this useful?
- In a _rebase-workflow_ (MR are preferably rebased before being merged), the reviewer wants to know if an MR is rebased on the target branch before merging it.
_With this indicator, the reviewer knows immediately if the branch is rebased, or if she needs to ask the committer to rebase its branch._
<br>
- To keep the git history readable, a team prefers to avoid merging branches that really lag a lot behind the target branch. Merging an MR that is 10 commits behind is fine, but 200 is too much.
_With this indicator, the reviewer can see on the MR page if the branch is really far behind the target – or only a few commits behind._
## Open questions
We've been using this at @captaintrain for a few months now, and found it quite useful.
I guess the open-questions are mostly: what UI would be the more adequate? Any thoughts on this, on the general usefulness and/or on the code?
See merge request !2217
|
| | | | | |
|
| | | |/
| |/|
| | |
| | | |
Button full width on phone on MR/issue.
|
| | |/ |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
* Not required to run hooks since it's an internal commit
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
In case merge request is broken, we shouldn't check if the sha
is mergable, as it will be null, and there's no point, as we know
that it's not mergable.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Hide remove source branch button when new commit is added to branch
Fixes #3339
This MR hides the 'Remove source branch' button when a new commit is added to the source branch
/cc @DouweM
See merge request !2701
|
| | |
| |
| |
| |
| |
| | |
Fixes #3339
This MR hides the 'Remove source branch' button when a new commit is added to the source branch
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| | |
No space required after WIP identifier
Fixes #2426
Currently, the WIP: (or any other variation) prefix of a merge request title must include a trailing space for it to be recognized as a work in progress and prevent merging.
To resolve this, I added an or pattern to the regexp to look for any one of the three possible delimiters ':', ']', or ' '. This way the trailing space isn't required but it still won't mark any titles beginning with wip as work in progress (e.g. "Wipwap").
See merge request !1876
|
| | |\ |
|
| | | |
| | |
| | |
| | | |
Modified changelog
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Optimize fetching issues closed by a merge request
Related issue: #12419
See merge request !2625
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of running ClosingIssueExtractor for every commit in a merge
request we can gather all the commit messages (and the merge request
description), concatenate all this together and then run
ClosingIssueExtractor only once.
The result of this is that MergeRequest#closes_issues is now between
3.5x and 4x faster than the old setup. Using a merge request with 10
commits (each referencing a number of issues to close) this reduced the
call duration from around 200 milliseconds to around 50 milliseconds.
As a result of these changes the Jira related tests for
MergeRequest#closes_issues have been removed. These tests stubbed
Commit#closes_issues meaning that the only code that was really tested
was the call to Array#uniq to filter out duplicate issues. As this code
is no longer used (nor present) the corresponding tests were removed.
Related: gitlab-org/gitlab-ce#12419
|
| | | | | |
|
| |/ / / |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \ |
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Improve performance of getting issues on group level
For testing I used the URL http://localhost:3000/groups/gitlab-org/issues?milestone_title=8.1. Prior to these changes said URL would take about 10-12 seconds to load. By applying these changes the loading time has been reduced to roughly 2-3 seconds.
There's still some stuff going on in some views that I have to look at, resolving those changes might reduce the loading time a bit more. I also still have to check if I didn't break too many tests.
Fixes: gitlab-org/gitlab-ce#3707 gitlab-org/gitlab-ce#4071
See merge request !2318
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
These scopes don't care about the order. Removing the explicit "ORDER
BY" can speed up the queries by a little bit.
|
