500 error encountered when browsing files #2410

Closed
alefmeemseen opened this Issue Dec 27, 2012 · 4 comments

Comments

Projects
None yet
2 participants

I just upgraded my Gitlab instance from 3.1 to 4-0-stable , when I browse any code file I get 500 error and here is the log :

Completed 500 Internal Server Error in 120ms

ActionView::Template::Error (Failed to get header.):
    9:   .file_content.code
    10:     - unless blob.empty?
    11:       %div{class: user_color_scheme_class}
    12:         = raw blob.colorize(formatter: :gitlab)
    13:     - else
    14:       %p.nothing_here_message Empty file
  app/models/tree.rb:5:in `colorize'
  app/views/tree/blob/_text.html.haml:12:in `_app_views_tree_blob__text_html_haml__857522388875419420_55507340'
  app/views/tree/_blob.html.haml:9:in `_app_views_tree__blob_html_haml___2533693189977314418_55458360'
  app/views/tree/_tree.html.haml:15:in `_app_views_tree__tree_html_haml___1664782134279665212_55472320'
  app/views/tree/show.js.haml:3:in `_app_views_tree_show_js_haml__4569430623983790506_55381760'

}

I have the exact same problem.

I can browse the directories of the repositories (File tab) but when I click on a file nothing happens.

If I click on the "View file @xxxxx" button on a commit page I get a 500 error page.

The error log looks the same.

I'm still having the problem. The weird thing is that I can "open" the "README.md" files and download binary files but not opening any other files.

I fixed my problems... there were configuration issues, after fixing all problems listed by running

'sudo -u gitlab -H bundle exec rake gitlab:check RAILS_ENV=production'

everything is working. Sorry for the spam.

Thanks fabianmenges , I fixed it by running checks again and solve the problems found.

@stanhu stanhu added a commit that referenced this issue Dec 28, 2015

@stanhu stanhu 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
ff8cd11

@randx randx added a commit that referenced this issue Dec 28, 2015

@randx randx Merge branch 'disable-git-follow' into 'master'
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 a every other entry 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

See merge request !2210
08b4d8b

@randx randx added a commit that referenced this issue Dec 29, 2015

@randx @tsigo randx + tsigo Merge branch 'disable-git-follow' into 'master'
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 a every other entry 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

See merge request !2210
795a29a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment