Fix settings_spec so that it can that run by itself
Running `spec/settings_spec.rb` would fail because it would attempt to load `1_settings.rb`, which would reference `Rails`. This constant was not loaded without `spec_helper.rb`.
See merge request !4893
Replace Haml with Hamlit
What this change does:
- It replaces HAML with [Hamlit](https://github.com/k0kubun/hamlit), a much more efficient implementation of HAML.
- It removes `haml-rails`.
- It adds `hamlit.rb` and removes `haml.rb`.
- It makes things faster and less memory-hungry!
See also #13201.
See merge request !3666
Resolve "Scrolling horz on iOS for the secondary nav is broken"
## What does this MR do?
Moves absolutely positioned `div`s outside of the scrolling container because mobile safari causes those elements to jump around on scroll.
## Are there points in the code the reviewer needs to double check?
Check on a real iPhone (was only able to check in iOS simulator)
## Why was this MR needed?
Mobile Safari.
## What are the relevant issue numbers?
Closes#18438
## Screenshots (if relevant)

See merge request !4869
Fix unwanted label unassignment
## What does this MR do?
- When updating the milestone
- [x] Do not remove labels when assigning a milestone
- [x] Do not remove labels when unassigning a milestone
- [x] Do not remove labels when assigning a milestone and adding another label
- When toggling selected issues labels should be kept
- [x] Select an issue with an assigned label -> pick another label from dropdown-> unselect the issue -> select the issue again -> submit the form: Existing label should not be removed.
## Are there points in the code the reviewer needs to double check?
Labels should not be added or removed to issues when doing bulk actions unless we explicitly select a label from the dropdown
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !4863
Use jQuery objects in ref dropdown
## What does this MR do?
Keeps the behaviour the same as the ref dropdown, however it now uses jQuery objects to handle the HTML creation instead of passing strings around. It pretty much worked out the box so not much was changed in the dropdowns themselves. Will be easy to transfer this over to other dropdown menus as well.
cc. @jschatz1 @rspeicher @DouweM
Do we want this to go into a patch release?
See merge request !4850
This commit eager loads the award emoji on both the issues and the MRs.
When loading an issue with 108 comments this reduces the query count by
327 queries. On a merge request with the same amount of comments this
saves 148 queries. The large difference is not clear to me at this
point and the total query count is still huge with 387 and 1034
respectively. The biggest problem however, remains the calculation of
participants.
Fix merge requests project settings help link anchor.
## What does this MR do?
8.9.0 added a new project option for merge requests which has a link for help. The link contained an anchor which was being encoded as ```%23``` so change the help link to properly configure the anchor.
## Are there points in the code the reviewer needs to double check?
None
## Why was this MR needed?
Current release causes 404 error when clicking on the help link in project settings.
## What are the relevant issue numbers?
Closes#18982
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !4873
Fix pagination on sorts with lots of ties
## What does this MR do?
Fixes#18915. As we only order by the sorted column, we don't have any tie-breaker. Some orderings, like priority and weight, have lots of ties, so you can see duplicate results as you page through. (Timestamp columns are less susceptible to this.)
## Are there points in the code the reviewer needs to double check?
I just picked `id DESC`, this could as easily be `id ASC`.
## Why was this MR needed?
Postgres and MySQL don't guarantee that pagination with `LIMIT` and
`OFFSET` will work as expected if the ordering isn't unique. From the Postgres docs:
> When using `LIMIT`, it is important to use an `ORDER BY` clause that
> constrains the result rows into a unique order. Otherwise you will get
> an unpredictable subset of the query's rows
Before:
[1] pry(main)> issues = 1.upto(Issue.count).map { |i| Issue.sort('priority').page(i).per(1).map(&:id) }.flatten
[2] pry(main)> issues.count
=> 81
[3] pry(main)> issues.uniq.count
=> 42
After:
[1] pry(main)> issues = 1.upto(Issue.count).map { |i| Issue.sort('priority').page(i).per(1).map(&:id) }.flatten
[2] pry(main)> issues.count
=> 81
[3] pry(main)> issues.uniq.count
=> 81
See merge request !4878
Postgres and MySQL don't guarantee that pagination with `LIMIT` and
`OFFSET` will work if the ordering isn't unique. From the Postgres docs:
> When using `LIMIT`, it is important to use an `ORDER BY` clause that
> constrains the result rows into a unique order. Otherwise you will get
> an unpredictable subset of the query's rows
Before:
[1] pry(main)> issues = 1.upto(Issue.count).map { |i| Issue.sort('priority').page(i).per(1).map(&:id) }.flatten
[2] pry(main)> issues.count
=> 81
[3] pry(main)> issues.uniq.count
=> 42
After:
[1] pry(main)> issues = 1.upto(Issue.count).map { |i| Issue.sort('priority').page(i).per(1).map(&:id) }.flatten
[2] pry(main)> issues.count
=> 81
[3] pry(main)> issues.uniq.count
=> 81