Add ability to fetch the commit ID of the last commit that actually touched a file

https://dev.gitlab.org/gitlab/gitlabhq/issues/2564

See merge request !1718

Reduce disk IO and space usage during backups

This is based on improvements made to the GitLab CI 8.0 backup script.

- Avoid creating many small intermediate files while backing up builds and uploads by using tar and light gzip compression
- Use same backup/restore code for uploads and builds
- Only store a compressed intermediate DB dump

See merge request !1520

Add custom protocol whitelisting to SanitizationFilter

Addresses internal https://dev.gitlab.org/gitlab/gitlabhq/issues/2613

We allow any protocol for autolinks: irc://irc.freenode.net/git

But manual Markdown links with the same protocol get sanitized: `[This will not be clickable](irc://irc.freenode.net/git)`: [This will not be clickable](irc://irc.freenode.net/git)

To get around this we have to first allow *all* protocols, and then manually clean dangerous (i.e., `javascript:`) protocols.

See merge request !1496

Persist blob editor's value on submit, not on click

Prior, the value of the Ace editor was only being persisted if the user
physically clicked the submit button, which the "quick submit" behavior
doesn't do.

Now the value will be properly transferred before any form is submitted.

See merge request !1712

Go to gitlab installation folder before initialize database

Gilab -> GitLab

Replace `Gitlab` with `GitLab`

See merge request !1715

Fix typo in rake task doc



See merge request !1713

Fix deadlink in docs for ci/examples

Just fix a deadlink in docs for ci/examples.

See merge request !1710

Prior, the value of the Ace editor was only being persisted if the user
physically clicked the submit button, which the "quick submit" behavior
doesn't do.

Now the value will be properly transferred before any form is submitted.

Switch to gitlab-workhorse

This is a little annoying but it is better to change this name then
to be stuck with a bad name for a long time. Reasons for the name
change: https://gitlab.com/gitlab-org/gitlab-git-http-server/issues/13

See merge request !1707

Improve performance of User.find_by_any_email



See merge request !1698

Minor ui fixes



See merge request !1704

While these benchmarks run at roughly 1500 i/sec setting the threshold
to 1000 leaves some room for deviations (e.g. due to different DB
setups).

This further improves performance of User.find_by_any_email and is
roughly twice as fast as the previous UNION setup.

Thanks again to @dlemstra for suggesting this.

MySQL doesn't support the previous syntax.

This is significantly faster than using a sub-query, at least when run
on the GitLab.com production database. The benchmarks are a lot slower
now with these changes, most likely due to PostgreSQL choosing a
different (and less efficient) plan based on the amount of data present
in the test database.

Thanks to @dlemstra for suggesting the use of a UNION.

This query used to rely on a JOIN, effectively producing the following
SQL:

    SELECT users.*
    FROM users
    LEFT OUTER JOIN emails ON emails.user_id = users.id
    WHERE (users.email = X OR emails.email = X)
    LIMIT 1;

The use of a JOIN means having to scan over all Emails and users, join
them together and then filter out the rows that don't match the criteria
(though this step may be taken into account already when joining).

In the new setup this query instead uses a sub-query, producing the
following SQL:

    SELECT *
    FROM users
    WHERE id IN (select user_id FROM emails WHERE email = X)
    OR email = X
    LIMIT 1;

This query has the benefit that it:

1. Doesn't have to JOIN any rows
2. Only has to operate on a relatively small set of rows from the
   "emails" table.

Since most users will only have a handful of Emails associated
(certainly not hundreds or even thousands) the size of the set returned
by the sub-query is small enough that it should not become problematic.

Performance of the old versus new version can be measured using the
following benchmark:

    # Save this in ./bench.rb
    require 'benchmark/ips'

    email = 'yorick@gitlab.com'

    def User.find_by_any_email_old(email)
      user_table = arel_table
      email_table = Email.arel_table

      query = user_table.
        project(user_table[Arel.star]).
        join(email_table, Arel::Nodes::OuterJoin).
        on(user_table[:id].eq(email_table[:user_id])).
        where(user_table[:email].eq(email).or(email_table[:email].eq(email)))

      find_by_sql(query.to_sql).first
    end

    Benchmark.ips do |bench|
      bench.report 'original' do
        User.find_by_any_email_old(email)
      end

      bench.report 'optimized' do
        User.find_by_any_email(email)
      end

      bench.compare!
    end

Running this locally using "bundle exec rails r bench.rb" produces the
following output:

    Calculating -------------------------------------
                original     1.000  i/100ms
               optimized    93.000  i/100ms
    -------------------------------------------------
                original     11.103  (± 0.0%) i/s -     56.000
               optimized    948.713  (± 5.3%) i/s -      4.743k

    Comparison:
               optimized:      948.7 i/s
                original:       11.1 i/s - 85.45x slower

In other words, the new setup is 85x faster compared to the old setup,
at least when running this benchmark locally.

For GitLab.com these improvements result in User.find_by_any_email
taking only ~170 ms to run, instead of around 800 ms. While this is
"only" an improvement of about 4.5 times (instead of 85x) it's still
significantly better than before.

Fixes #3242

Simply type a name with a `/` directory separator and new directories
will be created. This does not do the fancy UI work that github.com
does, but it will get the job done.

I could not find tests for file creation, so I didn't add a test for
this slight behaviour modification. I did test directory traversals
though, using both absolute paths like `/tmp/foo.txt` and relative paths
like `../../foo.txt`. Neither case escaped the repository, though
attempting to traverse with a relative path resulted in a 500 error that
did not affect application stability upon reload.

Force update refs/merge-requests/X/head upon a push to the source branch of a merge request

If a user rebases and does a force push, GitLab would not update the `refs/merge-requests/X/head` link. Using the -f flag forces this to happen.

Closes #3138

See merge request !1683

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

Start putting shared files in "shared"



See merge request !1691

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