To reproduce:
1. Create a project with some content
2. Rename the project
3. Create a new project with the same name.
4. Boom - 404.
After step 2, the branch and tag counts were not being cleared. This would
cause `repository.has_visible_content?` to erroneously return `true`
for the newly-created project.
Closes#13384
This caches the output of Repository#exists? in Redis while making sure
it's flushed properly when creating new repositories, deleting them,
etc.
For the ProjectWiki tests to work I had to make ProjectWiki#create_repo!
public as testing private methods in RSpec is a bit of a pain.
The avatar logic has been moved from Project to Repository as this makes
caching easier. The logic itself in turn has been changed so that the
logo file names are cached in Redis. This cache is flushed upon pushing
a commit but _only_ if:
1. The commit was pushed to the default branch
2. The commit actually changes any of the logo files
If no branch or commit is given the cache is flushed anyway, this
ensures that calling Repository#expire_cache without any arguments still
flushes the avatar cache (e.g. this is used when removing a project).
Fixesgitlab-org/gitlab-ce#14363
The methods used for this are Repository#tag_count and
Repository#branch_count which cache their output in Redis as well as
memoizing it in an instance variable. Both methods have a corresponding
methods/hooks to flush the caches at the right time.
This ensures that the emptiness cache (used for Repository#empty? and
Repository#has_visible_content?) is flushed after comitting changes
(using the web editor, API or Git) for new repositories. Once a
repository is no longer empty there's no need to explicitly flush the
cache for Repository#empty?. The cache for
Repository#has_visible_content? in turn is already flushed whenever
needed.
Fixesgitlab-org/gitlab-ce#13387
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.
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.
Fixesgitlab-org/gitlab-ce#13457
This ensures the caches for Repository#empty? and
Repository#has_visible_content? are flushed after a repository has been
imported or forked.
Fixesgitlab-org/gitlab-ce#13505
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.
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.