# Conflicts:
#	app/assets/stylesheets/pages/admin.scss
#	app/views/admin/users/index.html.haml

CE to EE for 8.10.0-rc1 (bis)

I'm merging CE to EE one last time before I tag 8.10.0-rc1!

See merge request !534

Signed-off-by: Rémy Coutable <remy@rymai.me>

Add information when member joined a team

## What does this MR do?
It adds timeago label by every member on team page
## Are there points in the code the reviewer needs to double check?

Yes, maybe design is not OK, please check.

## Why was this MR needed?

It's useful information

## What are the relevant issue numbers?

## Screenshots (if relevant)

![joxi_screenshot_1467820915126](/uploads/9e5657443a10a9fe204367d7b6749b1f/joxi_screenshot_1467820915126.png)



See merge request !5116

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Services: code style fixes, minor refactoring

## What does this MR do?

It contains code style fixes, minor refactoring and also it removes some unnecessary comments. Every comment require a support just like a regular code line and this is why we should avoid using comments everywhere unless it's really helpful. Martin Fowler said "Find comment and refactor the code around it" :) our code is not that bad so let's not spoil it with comments.

## Why was this MR needed?

Because GitLab is a live example of awesome code. Let's keep up a good job :) 


See merge request !5112

CE to EE for 8.10.0-rc1

Unresolved conflicts:

- `app/views/projects/_home_panel.html.haml`
- `app/views/shared/_clone_panel.html.haml`
- `app/helpers/projects_helper.rb`

@iamphill Could you please resolve the conflicts introduced by gitlab-org/gitlab-ce!4989 in `app/views/projects/_home_panel.html.haml` and check that project headers look good? Thanks in advance!

@patricio Could you please resolve the conflicts introduced by gitlab-org/gitlab-ce!4696 in `app/helpers/projects_helper.rb` and `app/views/shared/_clone_panel.html.haml`? Thanks in advance!

I need this to be able to release 8.10.0-rc1!

See merge request !528

Show last push widget in upstream after push to fork

## What does this MR do?

Show the last push widget in the upstream project when you push to a fork. 

## Are there points in the code the reviewer needs to double check?

In the view, I'm checking if `@project` in the first part of the conditional. I felt it was necessary in case `@project` wasn't an object in all cases. Will it ever not be there? Is this check necessary?

Should there be tests? I don't see existing ones for this. 

## Why was this MR needed?

I use the fork workflow everywhere and it has annoyed me for some time that the last push widget doesn't show up when viewing the upstream project. I'm almost never viewing the fork in GitLab so I want to be able to easily create a MR in any case. 

## Screenshots (if relevant)

**Widget in upstream repo:**

![Screen_Shot_2016-06-23_at_10.05.29_AM](/uploads/f823642e40cf059c3793db6cf00bba50/Screen_Shot_2016-06-23_at_10.05.29_AM.png)

**Widget in fork**:

![Screen_Shot_2016-06-23_at_10.05.25_AM](/uploads/1a976241186ec42cdc43c80bea0c856b/Screen_Shot_2016-06-23_at_10.05.25_AM.png)

**Widget on dashboard**:

![Screen_Shot_2016-06-23_at_10.06.07_AM](/uploads/084ac35f67735aec8042d9bc904255fe/Screen_Shot_2016-06-23_at_10.06.07_AM.png)


See merge request !4880

Allow everyone to order tags, not only those who has access

## What does this MR do?
Allows everyone to view tags by different order (by name, date, etc), not only those who has access

## Are there points in the code the reviewer needs to double check?
Just check how it's rendered.

## Why was this MR needed?
Because now I can't order other's project tags.

## What are the relevant issue numbers?
#15438

## Screenshots (if relevant)
Exist in related issue. Look [one comment](https://gitlab.com/gitlab-org/gitlab-ce/issues/15438#note_12888763) and [just below there is another one](https://gitlab.com/gitlab-org/gitlab-ce/issues/15438#note_12888819).

## Does this MR meet the acceptance criteria?
Probably, no need

See merge request !5105

Fixed issue with build auto-refresh not working

## What does this MR do?

Due to the `.json` at the end of the build URL fetch, the page wont correctly auto-reload the build log. This fixes that.

See merge request !5110

Get rid of pluralize on stage names

## What does this MR do?
Removes `pluralize` from stage names

## What are the relevant issue numbers?
Closes #18283   
Part of https://gitlab.com/gitlab-org/gitlab-ce/issues/18920

## Screenshots (if relevant)
![Screen_Shot_2016-07-06_at_11.11.39_AM](/uploads/b1b2dd00dc8aacc6dff40cab1fe1ecdd/Screen_Shot_2016-07-06_at_11.11.39_AM.png)

cc @ayufan 


See merge request !5117

Added 100% width to open dropdown menus on mobile

## What does this MR do?

Sets dropdown-menus to be 100% width on small screens.

## Are there points in the code the reviewer needs to double check?

Do we want this on all dropdown menus or only dropdown menus activated by full-width buttons?
/cc @dzaporozhets 

## Why was this MR needed?

Mobile UX.

## What are the relevant issue numbers?

Closes #18858.

## Screenshots (if relevant)

![Screen_Shot_2016-06-22_at_00.14.09](/uploads/bd61721896bfac8af951374c2547acd6/Screen_Shot_2016-06-22_at_00.14.09.png)

## Does this MR meet the acceptance criteria?

- [ ] [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 !4844

[ci skip]

[ci skip]

Revert "Merge branch 'fix_stale_last_owner' into 'master'"

This reverts merge request !529

Accidentally merged my own MR before review. Reverting and resubmitting. 

See merge request !530

This reverts merge request !529

Prevent stale data in LDAP group sync last owner check

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/17764

Customers were reporting that LDAP group sync would occasionally remove the last owner of a group. This didn't seem right (we have tests for this) so I dug in to see what was going on. Previously `owners` was a memoized method which was the reason for stale data. Now, it's an AR association and the same problem applies. The easiest solution is to reload the model before checking for last owner. 

See merge request !529

Fix erroneous YAML spacing in LDAP configuration

## What does this MR do?

Fix erroneous indentation in LDAP example configuration

## Are there points in the code the reviewer needs to double check?

Is the indentation correct now? 😂 

## Why was this MR needed?

Bad configs in docs suck.

See merge request !4326

Fix importer for GitHub Pull Requests when a branch was reused across Pull Requests

Closes #17766

## What does this MR do?

GitHub importer fails when a repository has two Pull Requests, with the same branch name and different SHA, one of which was closed without merging, and one which is open or was merged in. This happens because we only checks if the branch exists in the [Gitlab::GithubImport::BranchFormatter#exists?](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/github_import/branch_formatter.rb#L6-8), before creating the missing references on Github. With this MR we check if both branch, and SHA exists in the current project. If no, we create the missing reference on GitHub before import the PR.

## Are there points in the code the reviewer needs to double check?

Nope.

## Why was this MR needed?

Github importer will fail if branch was reused across Pull Requests.

## What are the relevant issue numbers?

https://gitlab.com/gitlab-org/gitlab-ce/issues/19439

/cc @royaldark @thomasjachmann

See merge request !5103

Signed-off-by: Rémy Coutable <remy@rymai.me>

Check fast-forward more precisely

The original issue is that (#260), some people want to be able to merge
a fast-forward MR regardless it's rebased or not. The previously
check for this: `target_sha == source_sha_parent`, assumes that the
questioning MR has a linear history (i.e. it's rebased), therefore
we could do a fast-forward merge. However, we could also do fast-forward
merge if the MR has already merged target branch (i.e. it's merged).

This MR would allow them to merge any fast-forward MR regardless rebased
or not.

But actually this breaks some assumption. In the option of:

> Merge commit with semi-linear history
>> A merge commit is created for every merge, but merging is only
>> allowed if the branch has been rebased. This way you get a history
>> that reads linearly (as with fast-forward merges), with the addition
>> of merge commits.
>> When the branch has not been rebased, the user is given the option to do
>> so.

It clearly says: `merging is only allowed if the branch has been rebased`
This MR would break this assumption. The same applies to:

> Fast-forward merge
>> No merge commits are created and all merges are fast-forwarded, which
>> means that merging is only allowed if the branch has been rebased.
>> When the branch has not been rebased, the user is given the option to do
>> so.

This means that rebase and FF are two separated concept and we're
mixing them here. We should probably update the wordings and perhaps
provide another option if we want to keep all the workflows.

My own thought is actually, allowing only FF merge might make little
sense. Allowing only FF *and* rebased (linear history) would make more
sense. That means I think the original behaviour actually makes more
sense, just that the wordings are wrong. i.e. They could be FF merged,
but that's not the point, we still want you to rebase this branch!

On the other hand, I am not against adding a new option for this
behaviour either. People have different workflows, and I think it makes
sense to allow any workflows which Git provided.

Either way, I think some wordings should be changed.

By the way, could we write a test for this?

Fixes #260

/cc @DouweM 

See merge request !454

Cancel creating or editing note by hitting Escape

/cc @rspeicher 

See merge request !5075

Don't expose repository credentials when raising error on mirror update.

REF: https://gitlab.com/gitlab-com/support-forum/issues/816

See merge request !527

Remove duplicate templates that are lowercase

See merge request !5114

Throttle the update of `project.pushes_since_gc` to 1 minute

## What does this MR do?

Throttle the update of `project.pushes_since_gc` to alleviate DB load

## What are the relevant issue numbers?

Relates to #15094

## 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~~
  - [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)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)


See merge request !5083