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: Dmitriy 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: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

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

Closes #3311

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

Fixed method to use git log via Popen as recommended, and made output match test (and thus system) expectations.

Include the log messages of recent commits in project-level search
results, providing functionality similar to 'git log --grep'.

Update repository model rspec tests to validate the output of
Repository#commits_with_log_matching.

Closes #3138

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

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