An error occurred fetching the project authors.
  1. 16 Jun, 2016 2 commits
  2. 12 Jun, 2016 1 commit
    • Stan Hu's avatar
      Fix Error 500 when viewing a blob with binary characters after the 1024-byte mark · 0fdfd2dd
      Stan Hu authored
      Here was the problem:
      
      1. When determining whether a given blob is viewable text, gitlab_git reads the first 1024 bytes and checks with Linguist whether it is a text or binary file.
      2. If the blob is text, GitLab will attempt to display it.
      3. However, if the text has binary characters after the first 1024 bytes, then GitLab will attempt to load the entire contents, but the encoding will be ASCII-8BIT since there are binary characters.
      4. The Error 500 results when GitLab attempts to display a mix UTF-8 and ASCII-8BIT.
      
      To fix this, we load as much data as we are willing to display so that the detection will work properly. Requires
      an update to gitlab_git: gitlab-org/gitlab_git!86
      
      Closes #13826
      0fdfd2dd
  3. 03 Jun, 2016 2 commits
  4. 20 May, 2016 3 commits
  5. 07 May, 2016 1 commit
  6. 28 Apr, 2016 1 commit
  7. 18 Apr, 2016 1 commit
  8. 07 Apr, 2016 1 commit
  9. 20 Mar, 2016 1 commit
  10. 07 Mar, 2016 2 commits
  11. 03 Mar, 2016 1 commit
  12. 24 Feb, 2016 1 commit
  13. 19 Feb, 2016 1 commit
    • Robert Speicher's avatar
      Add a `Blob` model that wraps `Gitlab::Git::Blob` · 8c454b36
      Robert Speicher authored
      This allows us to take advantage of Rails' `to_partial_path` to render
      the correct partial based on the Blob type, rather than cluttering the
      view with conditionals.
      
      It also allows (and will allow in the future) better encapsulation for
      Blob-related logic which makes sense for our Rails app but might not
      make as much sense for the core `gitlab_git` library, such as detecting
      if the blob is an SVG.
      8c454b36
  14. 01 Feb, 2016 1 commit
  15. 21 Jan, 2016 1 commit
  16. 20 Jan, 2016 2 commits
  17. 19 Jan, 2016 1 commit
  18. 14 Jan, 2016 2 commits
  19. 12 Jan, 2016 1 commit
  20. 30 Dec, 2015 1 commit
  21. 28 Dec, 2015 1 commit
  22. 18 Dec, 2015 3 commits
  23. 08 Dec, 2015 2 commits
  24. 07 Dec, 2015 2 commits
  25. 02 Dec, 2015 1 commit
  26. 09 Sep, 2015 1 commit
  27. 26 Aug, 2015 1 commit
  28. 29 Jul, 2015 2 commits
    • Stefan Tatschner's avatar
      Add HTMLGitlab formatter · 00ff84d3
      Stefan Tatschner authored
      This custom formatter for rouge is needed to generate HTML output
      specifically for gitlab. Since its usecase is mostly suitable for
      gitlab it had been rejected upstream:
      https://github.com/jneen/rouge/pull/268
      
      Thanks a lot to @stanhu, @jneen and @tsigo for review!
      00ff84d3
    • Stefan Tatschner's avatar
      Replace Rugments with Rouge · f736721c
      Stefan Tatschner authored
      I have mainly created the rugments fork for the purpose of improving
      gitlab's highlighting. Nowadays IMO it works way better than the old
      highlight.js solution. But the development is stuck on my side because
      of a couple of personal reasons:
      
        * I have finished my studies; last months I was writing my master
          thesis. So there was a huge time problem. I am sorry for that.
      
        * I had to move to Munich due to getting a (paid) job. Searching a
          flat here is horrible... :)
      
        * Last but not least, maintaining the same code base in two seperate
          projects is a mess.
      
      I have decided to switch back to rouge due to several reasons:
      
        * In the beginning I was quite motivated, but since I start
          working on my new job next week, the best solution IMO is
          switching back to upstream rouge.
      
        * Rouge is continously improving:
          https://github.com/jneen/rouge/blob/master/CHANGELOG.md
          http://rouge.jneen.net/
      
        * There should be absolutely no regressions with this change. Most
          likely this pull request will almost fix some minor bugs.
      
        * One less gem in gitlab is a good thing. since Gitlab is quite a
          huge bundle of gems. Reducing complexity should be a major
          milestone.
      
      Thanks a lot to @stanhu and @jneen for the review!
      f736721c