1. 28 Jan, 2016 1 commit
  2. 22 Jan, 2016 1 commit
  3. 21 Jan, 2016 1 commit
  4. 07 Jan, 2016 3 commits
  5. 25 Dec, 2015 1 commit
    • 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
  6. 18 Dec, 2015 1 commit
  7. 15 Dec, 2015 1 commit
    • Jeff Stubler's avatar
      Fix diverging commit count calculation · d1b476b4cadb
      Jeff Stubler authored
      Rugged seemed to stop accepting branch names as valid refs, throwing `Rugged::ReferenceError` exceptions. Now the branch target rather than branch name is used, and the default branch's hash is also calculated, and these work properly.
      
      This used to work and might be something worth re-investigating in the future.
      d1b476b4cadb
  8. 10 Dec, 2015 1 commit
  9. 08 Dec, 2015 1 commit
  10. 07 Dec, 2015 1 commit
  11. 03 Dec, 2015 1 commit
  12. 30 Nov, 2015 1 commit
  13. 18 Nov, 2015 3 commits
  14. 16 Nov, 2015 1 commit
  15. 11 Nov, 2015 1 commit
  16. 03 Nov, 2015 1 commit
  17. 02 Nov, 2015 1 commit
  18. 01 Nov, 2015 1 commit
  19. 29 Oct, 2015 4 commits
  20. 28 Oct, 2015 1 commit
  21. 23 Oct, 2015 2 commits
  22. 21 Oct, 2015 2 commits
  23. 20 Oct, 2015 2 commits
  24. 16 Oct, 2015 1 commit
  25. 15 Oct, 2015 1 commit
  26. 14 Oct, 2015 2 commits
  27. 07 Oct, 2015 1 commit
    • Stan Hu's avatar
      Add directory feature button · 4e2ffdbe1acd
      Stan Hu authored
      Change "+" icon under "Files" section to have three options:
      
      * Create file
      * Upload file
      * New directory
      
      Upload file is no longer accessible from the "Create file" page.
      Users can now select a target branch in upload file as well.
      
      Closes #2799: Fixes a bug where file modes were overwritten after a commit
      
      Closes https://github.com/gitlabhq/gitlabhq/issues/8253: Existing files
      can no longer be overwritten in the "Create file" section.
      
      Closes #2557
      4e2ffdbe1acd
  28. 03 Oct, 2015 1 commit
  29. 17 Aug, 2015 1 commit