1. 06 Jan, 2016 1 commit
  2. 05 Jan, 2016 5 commits
  3. 04 Jan, 2016 5 commits
  4. 03 Jan, 2016 1 commit
  5. 01 Jan, 2016 1 commit
  6. 31 Dec, 2015 3 commits
  7. 30 Dec, 2015 1 commit
  8. 29 Dec, 2015 2 commits
  9. 27 Dec, 2015 1 commit
  10. 25 Dec, 2015 2 commits
    • Valery Sizov's avatar
      a1b63e12
    • Stan Hu's avatar
      Disable --follow in `git log` to avoid loading duplicate commit data in infinite scroll · ff8cd116
      Stan Hu authored
      `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
      ff8cd116
  11. 24 Dec, 2015 7 commits
  12. 23 Dec, 2015 1 commit
  13. 22 Dec, 2015 6 commits
    • Stan Hu's avatar
      Fix Error 500 when global milestones have slashes · 34695569
      Stan Hu authored
      Closes #4226
      34695569
    • Valery Sizov's avatar
      d794ae8e
    • Stan Hu's avatar
      Fix Error 500 when doing a search in dashboard before visiting any project · 4949f40a
      Stan Hu authored
      If a search turned up an issue, under certain conditions you would see this error:
      
      ```
      ActionView::Template::Error (undefined method `path_with_namespace' for nil:NilClass):
           6:   - if issue.description.present?
           7:     .description.term
           8:       = preserve do
           9:         = search_md_sanitize(markdown(issue.description))
          10:   %span.light
          11:     #{issue.project.name_with_namespace}
          12:   - if issue.closed?
        lib/gitlab/markdown/upload_link_filter.rb:36:in `build_url'
        lib/gitlab/markdown/upload_link_filter.rb:31:in `process_link_attr'
        lib/gitlab/markdown/upload_link_filter.rb:18:in `block in call'
        lib/gitlab/markdown/upload_link_filter.rb:17:in `call'
        lib/gitlab/markdown.rb:127:in `gfm'
        lib/gitlab/markdown.rb:24:in `render'
        app/helpers/gitlab_markdown_helper.rb:61:in `markdown'
        app/views/search/results/_issue.html.haml:9:in `block in _app_views_search_results__issue_html_haml__4127460390996300432_59973760'
        app/views/search/results/_issue.html.haml:8:in `_app_views_search_results__issue_html_haml__4127460390996300432_59973760'
        app/views/search/_results.html.haml:20:in `_app_views_search__results_html_haml__589475855773452465_61761440'
        app/views/search/show.html.haml:5:in `_app_views_search_show_html_haml___1852335078065998536_69780120'
      ```
      4949f40a
    • Stan Hu's avatar
      Add project permissions to all project API endpoints · 301a30e0
      Stan Hu authored
      This standardizes all the project API formats. Also needed to support Huboard.
      301a30e0
    • Dmitriy Zaporozhets's avatar
      8516b205
    • Kamil Trzcinski's avatar
      Update CHANGELOG · f8986e4b
      Kamil Trzcinski authored
      f8986e4b
  14. 21 Dec, 2015 3 commits
  15. 18 Dec, 2015 1 commit