Read about our upcoming Code of Conduct on this issue

  1. 29 Dec, 2015 3 commits
  2. 28 Dec, 2015 3 commits
  3. 25 Dec, 2015 2 commits
    • Valery Sizov's avatar
      revert back vote buttons to issue and MR pages · 619e85df9678
      Valery Sizov authored
      619e85df9678
    • Stan Hu's avatar
      Disable --follow in `git log` to avoid loading duplicate commit data in infinite scroll · ec573bdc12b9
      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
      ec573bdc12b9
  4. 24 Dec, 2015 3 commits
  5. 23 Dec, 2015 3 commits
  6. 22 Dec, 2015 2 commits
  7. 21 Dec, 2015 2 commits
  8. 20 Dec, 2015 1 commit
  9. 18 Dec, 2015 2 commits
  10. 17 Dec, 2015 2 commits
  11. 16 Dec, 2015 4 commits
    • Douwe Maan's avatar
    • Rubén Dávila's avatar
      Add link to MR from Build detail page. #3452 · 24b9fb87efb3
      Rubén Dávila authored
      24b9fb87efb3
    • Stan Hu's avatar
      Fix bad merge · eb11a86027ad
      Stan Hu authored
      eb11a86027ad
    • Jason Lee's avatar
      Avoid allocations in Ability class. · 503f352bcebd
      Jason Lee authored
      It won't change anything after they are first invoke, so add method cache to avoid allocations and avoid GC.
      
      Benchmarks:
      
      ```
      Calculating -------------------------------------
      project_guest_rules without method cache
                              79.352k i/100ms
      project_guest_rules with method cache
                              93.634k i/100ms
      -------------------------------------------------
      project_guest_rules without method cache
                                2.865M (±32.5%) i/s -     11.982M
      project_guest_rules with method cache
                                4.419M (± 7.4%) i/s -     22.004M
      
      Comparison:
      project_guest_rules with method cache:  4418908.0 i/s
      project_guest_rules without method cache:  2864514.0 i/s - 1.54x slower
      
      Calculating -------------------------------------
      project_report_rules without method cache
                              53.126k i/100ms
      project_report_rules with method cache
                              97.473k i/100ms
      -------------------------------------------------
      project_report_rules without method cache
                                1.093M (±36.5%) i/s -      4.675M
      project_report_rules with method cache
                                4.420M (± 7.2%) i/s -     22.029M
      Comparison:
      project_report_rules with method cache:  4420054.3 i/s
      project_report_rules without method cache:  1092509.6 i/s - 4.05x slower
      ```
      
      https://gist.github.com/huacnlee/b04788ae6df42fe769e4
      503f352bcebd
  12. 15 Dec, 2015 5 commits
  13. 14 Dec, 2015 2 commits
  14. 12 Dec, 2015 1 commit
  15. 11 Dec, 2015 5 commits