FindCommits: avoid looping explosions related to `follow`
Correctly treats the case of ancestors of a single rev, ignores follow
in range notation cases
Merge request reports
Activity
assigned to @gracinet
A quick search in the Rails app code base reveals that, as of upstream v15.2.4,
follow
is automatically set for paths requests with exactly one path (app/models/repository.rb
):def commits(ref = nil, opts = {}) options = { repo: raw_repository, ref: ref, path: opts[:path], author: opts[:author], follow: Array(opts[:path]).length == 1, limit: opts[:limit], offset: opts[:offset], skip_merges: !!opts[:skip_merges], after: opts[:after], before: opts[:before], all: !!opts[:all], first_parent: !!opts[:first_parent], order: opts[:order], literal_pathspec: opts.fetch(:literal_pathspec, true), trailers: opts[:trailers] } commits = Gitlab::Git::Commit.where(options)
This is the only caller from the
app
layer. The parameter is exposed from thelib
layer inCommit.where
andGit::Repository#log
.Unfortunately, this
Repository#commits
is in turn used quite generically from the uper layers (controllers, services) and it is therefore quite possible to have Range Notation revspecs together with a singlepath
, possibly by accident (meaning that copy tracing would not matter much for the caller).