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
Updated dropdown CSS
This is a start on #3279 by updating the CSS for the dropdown menu. This doesnt include any CSS for the title bar or filter field
See merge request !3092
Based on however I changed the tabindex of the search field so that it goes search field -> filter field & then back to browser default. I dont think we should override the default tabindex of the page too much
Closes#3706
Include pagination for other than projects search
Pagination for projects results is already added on views/shared/projects/_list.html.haml
Fixes#13933
See merge request !3056
1. Fix double bottom border if pagination
2. Fix broken search on forks page
4. Remove duplicate js logic
4. Remove unused show all link
5. Remove duplicate “no project” message in different views
After this merge request you can easily render shared projects template
with all necessary html/js included to make searchable list with
pagination. All you need to provide is controller that returns
projects list with seach nad pagination and render html form with
project-filter-form id and text field with filter_projects name.
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Only show group member roles if explicitly requested
This very simply fixes an EE problem, but I made the change here so it's less prone to errors from merges.
In EE, prior to this change, group member roles were shown in project member list when a project is shared with a group. This is bad because the project explicitly shares with the group and sets a 'max access' level. If the max access level is 'developer' the project owner doesn't want to see 'Owner' in the group roles because it will confuse them. I verified that permissions are really being honored here, it was just an error in the view. You can see in https://gitlab.com/gitlab-org/gitlab-ee/blob/master/app/views/projects/project_members/_shared_group_members.html.haml#L18 where this was how it was intended to be. Likely a CE-EE merge introduced this bug. That's why I made the boolean required in CE even though this is for EE.
## Before
## After
See merge request !3044
Douwe Maan
Dmitriy Zaporozhets
Jacob Schatz
Jacob Schatz
Phil Hughes
Robert Speicher
Jacob Vosmaer
Pierre de La Morinerie
Alfredo Sumaran
Robert Speicher
Rémy Coutable
