When we updated gitlab_git to 10.4.1, `tag.target` changed from pointing
to the sha of the tag to the sha of the commit the tag points to. The
problem is that only annotated tags have `object_sha`s, lightweight tags
don't (it's nil), so (only) in their case we still need to use
`tag.target`.

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

After a project import, there's a chance that the UI checks the
branch count before the project has been imported. This change
causes more of the keys to be flushed after an import and forces
a rebuild of the repository cache.

Closes #13518

Fixes #21800.

If `git gc` runs and `Repository` has an instance to `Rugged::Repository`, a
bug in libgit2 may cause the instance to return a stale value or a missing
branch. This change not only optimizes the branch lookup so we don't have
to iterate through every branch, but it also works around the `git gc`
issue by forcing a repository reload every time `Repository#find_branch`
is called.

See: https://github.com/libgit2/libgit2/issues/1534

Closes #15392, #21470

- It sets the `in_progress_merge_commit_sha` variable on the given merge
  request, so that the branch permissions (developers can merge) check
  can proceed in the `pre-receive` hook.

So we have raw_diffs too

Project and branch cache is expired when project is still
empty or new branch is created. develops tests accordingly
Signed-off-by: NRémy Coutable <remy@rymai.me>

This reverts merge request !5375

We were seeing a number of error messages when attempting to create a keep-around ref:

1. Failed to create locked file `refs/keep-around/XYZ`: File exists
2. Failed to write reference `refs/keep-around/XYZ`: a reference with that name already exists.

I'm not sure how these happen, but I suspect when multiple workers attempt to write the same
file we may have an issue. The force parameter should help ensure the file gets created,
as well as the rescues to prevent 500 Errors.

Rugged/libgit2 unfortunately do not allow you to delete or re-create a reference that has
been corrupted, even with the force parameter.

Closes #20109

Replace invocation of `find` with Ruby code that matches old cached
files in a better, and safe way to avoid data-integrity issues.

This reverts commit 530f5158.

See !4892.
Signed-off-by: NRémy Coutable <remy@rymai.me>

This reverts commit 9ca633eb, reversing
changes made to fb229bbf.

1. When a merge request is being merged, save the merge commit SHA in
   the `in_progress_merge_commit_sha` database column.

2. The `pre-receive` hook looks for any locked (in progress) merge
   request with `in_progress_merge_commit_sha` matching the `newrev` it
   is passed.

3. If it finds a matching MR, the merge is legitimate.

4. Update `git_access_spec` to test the behaviour we added here. Also
   refactored this spec a bit to make it easier to add more contexts / conditions.

When pushing commits to existing branches we don’t
need to flush branch git data (branch names / counts)

When flushes the cache when pushing commits skip to
flush branch and tag git data (names / counts) because
those operations are managed explicitly in each case

Repopulated expired cache as soon as possible

This reverts commit 3e991230.