diff options
author | Stan Hu <stanhu@gmail.com> | 2015-12-25 01:07:00 -0800 |
---|---|---|
committer | Stan Hu <stanhu@gmail.com> | 2015-12-25 01:28:33 -0800 |
commit | ff8cd116a04d187f63222b3b29ebb6818dfd65e5 (patch) | |
tree | 75604ec8ac2de37c163297a8b94e0a785e8d9652 | |
parent | 350d65503f0fa34ae397942578c5ea8b2a46a629 (diff) | |
download | gitlab-ce-ff8cd116a04d187f63222b3b29ebb6818dfd65e5.tar.gz |
Disable --follow in `git log` to avoid loading duplicate commit data in infinite scroll
`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
-rw-r--r-- | CHANGELOG | 1 | ||||
-rw-r--r-- | app/models/repository.rb | 4 |
2 files changed, 4 insertions, 1 deletions
diff --git a/CHANGELOG b/CHANGELOG index 2e12889cb70..f110b16e1f2 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -10,6 +10,7 @@ v 8.4.0 (unreleased) - Add link to merge request on build detail page. v 8.3.2 (unreleased) + - Disable --follow in `git log` to avoid loading duplicate commit data in infinite scroll (Stan Hu) - Enable "Add key" button when user fills in a proper key v 8.3.1 diff --git a/app/models/repository.rb b/app/models/repository.rb index 9f688e3b45b..a9bf4eb4033 100644 --- a/app/models/repository.rb +++ b/app/models/repository.rb @@ -76,7 +76,9 @@ class Repository path: path, limit: limit, offset: offset, - follow: path.present? + # --follow doesn't play well with --skip. See: + # https://gitlab.com/gitlab-org/gitlab-ce/issues/3574#note_3040520 + follow: false } commits = Gitlab::Git::Commit.where(options) |