Reactivate highlight.js language autodetection
### What does this MR do?
This commit partly reverts commit 0d13abb1 to reactivate highlight.js language autodetection.
It does NOT revert the part that adds the `nohighlight` CSS-class for a predefined set of filenames (which was indeed the intended purpose of commit 0d13abb1).
### Are there points in the code the reviewer needs to double check?
Not particularly, the only effect of this blob_helper is to add a CSS class to the `<pre>` container of the blob, to control the way highlight.js performs its syntax highlighting. (see where this helper is called at https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/views/shared/_file_hljs.html.haml#L12).
However this merge request DOES change the way the syntax highlighting is done (by bringing it back to the situation before commit 0d13abb1 where highlight.js autodetected the language itself). So we can expect some new kind of syntax highlighting problems. However in this case, the issues should be forwarded to the upstream project (https://github.com/isagalaev/highlight.js).
### Why was this MR needed?
The main motivation behind this partial revert is that there is no point (IMHO) in using an "intelligent" syntax highlighter which is specifically designed to autodetect languages if it is to dictate (via the CSS class) the language to use solely based on the filename extension.
### What are the relevant issue numbers / Feature requests?
Issue #665 "HLJS language autodetection / syntax highlighting fails "
### Screenshots (If appropriate)
See screenshots in issue #665
See merge request !232
HipChat allows users to run their own private servers and to be able to
support those we must connect to the correct URL when using one of these
custom servers.
HipChat refers to their own product camel cased so we should do the
same. HipChat no longer recommends people use the deprecated v1 API so
switch to using the v2 API by default. hipchat-rb does not yet default
to v2 in any version so it must be specified.
Fork to group
Fixes#1592
* project can be forked into group
* fork link always lead to fork page where you select namespace where to fork
See merge request !1253
Run 'GC.start' after every EmailsOnPushWorker job
This change removed a lot of large peaks of the Sidekiq memory growth graph on gitlab.com.
See merge request !1257
* Show namespace thumbnail differently if project was already forked
* Show loading spinner when click on fork
* Fork link navigates to personal namespace only if no manageable groups exists
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Now you can fork project into group or personal namespace.
Also I moved fork logic from ProjectsController to own fork resource
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
If project has open merge request from fork and this fork was removed
before merge request was closed it cause exception during push
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Better merge request manual instructions
I noticed the current instructions for manually merging a merge request that was submitted from a fork could create unnecessary merge requests or strange history. Imagine this:
1. Alice creates a repository and commits / pushes a single commit with SHA1 `A` to `master`.
2. Bob forks this repository and creates a new branch `myfeature` on `master` (`A`)
3. Alice commits `B` to `master` (which has the parent `A`)
4. Bob creates two commits on `myfeature` `P` and `Q`.
5. Bob submits the merge request to merge his `myfeature` into Alice's `master` branch.
6. Alice follows the manual merge request instructions:
1. `git checkout -b bob/repo-myfeature master`
2. `git pull http://... myfeature`
The branch `bob/repo-myfeature` was created from Alice's current `master`, which was `B`. When the `pull` is executed, git will fetch Bob's branch and then merged the fetched branch `Q` into the current branch's location `B`. This creates an unnecessary merge commit from `master` into the branch Alice is trying to merge. No harm is done, but the history is a bit messier.
This is even worse if Alice has set `git pull` to rebase by default. In this case, the commit `B` is rebased on top of `Q`. When Alice checks out `master` and merges in the branch, there will actually be a duplicate `B` commit.
These new instructions instead tell the user to fetch Bob's `myfeature` branch. This will fetch the necessary commits `P` and `Q` and create a temporary ref `FETCH_HEAD` pointing to `Q`. Alice will then create her local `bob/repo-myfeature` branch starting at `FETCH_HEAD`. No unnecessary merge commits, and no accidental rebasing.
See merge request !16
Dmitriy Zaporozhets
Jacob Vosmaer
Marin Jankovski
Stefan Tatschner
Valery Sizov
Daniel AquinoandDoug Goldstein
ZertrinandMarc Gallet
Dmitriy Zaporozhets
Ciro Santilli
Marin Jankovski
Ben Bodenmiller
Nikita Verkhovin
skv
