* Not required to run hooks since it's an internal commit

If path_with_namespace is nil Repository#raw_repository will also return
nil. Apparently code out there creates a Repository instance without a
namespace path. Right.

Just checking raw_repository is no longer accurate to determine if a
repository exists or not.

Now that Repository#raw_repository no longer sets the autocrlf option it
will also no longer raise any NoRepository errors since it doesn't
access Rugged any more. This also means that Repository#exists? can't
simply return the raw repository as this is no indication of whether or
not the repository actually exists (besides returning a non boolean is
weird in the first place).

To solve this problem Repository#exists? now properly checks if the
repository exists and returns true/false instead of a
Gitlab::Git::Repository or nil object.

Setting the "autocrlf" Git option is an overkill since it's rarely
actually needed. More importantly, it has quite the impact on
performance (see gitlab-org/gitlab-ce#13457 for more information).

By setting "autocrlf" when creating or updating files we guarantee the
option is always set properly when we actually need it _without_
introducing overhead for requests that have nothing to do with this
option.

Fixes gitlab-org/gitlab-ce#13457

This ensures that _all_ caches (including any caches normally only
flushed under certain conditions) are flushed whenever a project is
removed. Because cache keys are based on project namespaces (excluding
IDs) not doing so could result in a newly created project re-using old
caches (if the project was re-created using the same name).

This ensures the caches for Repository#empty? and
Repository#has_visible_content? are flushed after a repository has been
imported or forked.

Fixes gitlab-org/gitlab-ce#13505

The "default_branch" argument is never used and the "project" argument
isn't optional.

Instead of flushing the behind/ahead counts for all branches upon every
push we now only flush the cache of branches that actually need to have
these statistics recalculated. There are now basically 2 scenarios and
their effects:

1. A user pushes a commit to the default branch, this results in the
   cache being flushed for all branches.
2. A user pushes to a non default branch, this results in _only_ the
   cache for that branch being flushed.

The existing code (Repository#expire_cache) remains backwards compatible
with the previous behaviour, the new behaviour is only applied when a
branch name is passed as an argument. This ensures that when for example
a project is deleted the cache for all branches is flushed.

This caches the output of the following methods:

* Repository#empty?
* Repository#has_visible_content?
* Repository#root_ref

The cache for Repository#has_visible_content? is flushed whenever a
commit is pushed to a new branch or an existing branch is removed.
The cache for Repository#root_ref is only flushed whenever a user
changes the default branch of a project. The cache for Repository#empty?
is never explicitly flushed as there's no need for it.

gitlab_git 8.1 adds the ability to count the amount of commits between
two references without having to allocate anything but regular
Rugged::Commit objects. This in turn speeds up the process of counting
the number of commits a branch is ahead/behind by about 3.5x.

Leaving out the -I option in "git grep" would cause an Error 500 because the
resulting line would include "Binary file X matches"

Gitlab::Git::Repository#branch_count is a tad faster than the previous
setup. See gitlab-org/gitlab_git!62 for more information.

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

Using the fuzzy filter, develop "file finder" feature.
- feedback(http://feedback.gitlab.com/forums/176466-general/suggestions/4987909-add-file-finder-fuzzy-input-in-files-tab-to-ju )
- fuzzy filter(https://github.com/jeancroy/fuzzaldrin-plus)
- shortcuts(when "t" was hitted at tree view, go to 'file find' page and 'esc' is to go back)
- depends on gitlab_git 7.2.22

`git` doesn't work properly when `--follow` and `--skip` are specified together. We could even be **omitting commits in the Web log** as a result.

Here are the gory details. Let's say you ran:

```
git log -n=5 --skip=2 README
```

This is the working case since it omits `--follow`. This is what happens:

1. `git` starts at `HEAD` and traverses down the tree until it finds the top-most commit relevant to README.
2. Once this is found, this commit is returned via `get_revision_1()`.
3. If the `skip_count` is positive, decrement and repeat step 2. Otherwise go onto step 4.
4. `show_log()` gets called with that commit.
5. Repeat step 1 until we have all five entries.

That's exactly what we want. What happens when you use `--follow`? You have to understand how step 1 is performed:

* When you specify a pathspec on the command-line (e.g. README), a flag `prune` [gets set here](https://github.com/git/git/blob/master/revision.c#L2351).
* If the `prune` flag is active, `get_commit_action()` determines whether the commit should be [scanned for matching paths](https://github.com/git/git/blob/master/revision.c#L2989).
* In the case of `--follow`, however, `prune` is [disabled here](https://github.com/git/git/blob/master/revision.c#L2350).
* As a result, a commit is never scanned for matching paths and therefore never pruned. `HEAD` will always get returned as the first commit, even if it's not relevant to the README.
* Making matters worse, the `--skip` in the example above would actually skip every other after `HEAD` N times. If README were changed in these skipped commits, we would actually miss information!

Since git uses a matching algorithm to determine whether a file was renamed, I
believe `git` needs to generate a diff of each commit to do this and traverse
each commit one-by-one to do this. I think that's the rationale for disabling
the `prune` functionality since you can't just do a simple string comparison.

Closes #4181, #4229, #3574, #2410

Rugged seemed to stop accepting branch names as valid refs, throwing `Rugged::ReferenceError` exceptions. Now the branch target rather than branch name is used, and the default branch's hash is also calculated, and these work properly.

This used to work and might be something worth re-investigating in the future.

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