Show incompatible projects in Bitbucket import status
### What does this MR do?
This MR displays incompatible Bitbucket projects (e.g. SVN, hg) in the status table.
### Why was this MR needed?
Users are confused when they don't see projects show up. The import list should show incompatible projects as we do for Google Code to make it more obvious to the user what is happening. (See !586 and 9c76a6fa).
### Screenshot

### What are the relevant issue numbers?
#1871
See merge request !1114
HTML span elements only apply to a single line, and in the case of multi-line
comments, the highlighting was dropped as a result. Ensure that each line has
the proper styling to fix this.
Closes#1577
Check that hooks directory exists before attempting to call realpath
This MR checks that the hooks directories actually exist before attempting to resolve their `realpath`.
Users who attempted to restore from source to an omnibus installation would get ugly errors when running `gitlab-rake gitlab:check`:
```
Errno::ENOENT: No such file or directory @ realpath_rec - /var/opt/gitlab/git-data/repositories/Wanda/www.git/hooks
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/check.rake:488:in `realpath'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/check.rake:488:in `block in check_repos_hooks_directory_is_link'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.1.11/lib/active_record/relation/batches.rb:52:in `block (2 levels) in find_each'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.1.11/lib/active_record/relation/batches.rb:52:in `each'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.1.11/lib/active_record/relation/batches.rb:52:in `block in find_each'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.1.11/lib/active_record/relation/batches.rb:126:in `find_in_batches'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.1.11/lib/active_record/relation/batches.rb:51:in `find_each'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.1.11/lib/active_record/querying.rb:9:in `find_each'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/check.rake:482:in `check_repos_hooks_directory_is_link'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/check.rake:343:in `block (3 levels) in <top (required)>'
Tasks: TOP => gitlab:check => gitlab:gitlab_shell:check
```
Closes#2121#2082
See merge request !1068
Add gitlab-shell to error message to give user a clue that something may be wrong there.
Ran into this in #2082. User was told that repositories were created when they were
not due to hooks symlink being wrong.
This custom formatter for rouge is needed to generate HTML output
specifically for gitlab. Since its usecase is mostly suitable for
gitlab it had been rejected upstream:
https://github.com/jneen/rouge/pull/268
Thanks a lot to @stanhu, @jneen and @tsigo for review!
I have mainly created the rugments fork for the purpose of improving
gitlab's highlighting. Nowadays IMO it works way better than the old
highlight.js solution. But the development is stuck on my side because
of a couple of personal reasons:
* I have finished my studies; last months I was writing my master
thesis. So there was a huge time problem. I am sorry for that.
* I had to move to Munich due to getting a (paid) job. Searching a
flat here is horrible... :)
* Last but not least, maintaining the same code base in two seperate
projects is a mess.
I have decided to switch back to rouge due to several reasons:
* In the beginning I was quite motivated, but since I start
working on my new job next week, the best solution IMO is
switching back to upstream rouge.
* Rouge is continously improving:
https://github.com/jneen/rouge/blob/master/CHANGELOG.mdhttp://rouge.jneen.net/
* There should be absolutely no regressions with this change. Most
likely this pull request will almost fix some minor bugs.
* One less gem in gitlab is a good thing. since Gitlab is quite a
huge bundle of gems. Reducing complexity should be a major
milestone.
Thanks a lot to @stanhu and @jneen for the review!
https://gitlab.com/gitlab-org/gitlab-git-http-server
This change introduces the GITLAB_GRACK_AUTH_ONLY environment
variable. When set, Grack requests to GitLab will only respond with
the user's GL_ID (if the request is OK) or an error. This allows
gitlab-git-http-server to use the main GitLab application as an
authentication and authorization backend.
If we like how this works we should drop the GITLAB_GRACK_AUTH_ONLY
variable at some point in the future.
Starting with migration `20150717130904` commit count is stored in the
database. For existing projects it defaults to `0` and is updated to the
correct value when commits are pushed.
The newly introduced rake task updates the commit count for all projects
which have not been updated yet.
Refs !986, !989, #2040.