1. 06 Mar, 2016 1 commit
    • Kirill Smelkov's avatar
      NXD Teach GitLab about patches · 827d3914
      Kirill Smelkov authored
      Teach GitLab not only to merge changes from a merge-request, but also to
      apply patches posted to merge-request in a way like `git am` would do -
      without merge commit and directly on top of current branch. Which way to
      go is selected by user in web UI, and apply patches is the first option.
      There are 3 cases:
      - only 1 commit is present in MR -> the only available option is to
        apply that single commit as one patch without a merge
        ( There is no need for merge commit in this case at all: information
          about user who applied the patch goes to "Committer" field in resultant
          commit. Avoiding 1 merge per 1 patch results in cleaner history )
        It is also possible to review patch description directly in web UI,
        before doing the actual application, and correct / amend it as needed.
      - several commits are present in MR:
        * it is possible to apply the patches directly on top of current
          branch. Again information about who applied what goes to "Committer"
        * it is possible to merge MR changes with making a merge commit.
          This variant is useful, when patches from a MR do several logical
          steps to reach one goal, and MR description contain cover letter for
          whole patch series.
          in this case original commits stay untouched and resulting merge
          will contain MR author as author, user who accepted MR as committer,
          and cover letter as merge commit message.
          NOTE we avoid useless "Merge branch X into Y" in merge message, and
              just put MR title into merge subject and MR description into merge
              This way it is more logical with more important information in
              merge subject and thus e.g. more handy to oversee what a merge brings,
              just by it subject, e.g. via looking at updates via
                  gitk --first-parent ...
              or via web.
      NOTE for pre-generated references to merge-request we now use full MR
          URL, instead of !<MR-n>. Full URLs work everywhere, not only on
          original site where MR was created, or even only in original repo
          and not its fork on the same site.
  2. 21 Feb, 2016 1 commit
  3. 19 Feb, 2016 2 commits
  4. 17 Feb, 2016 3 commits
  5. 16 Feb, 2016 1 commit
  6. 09 Feb, 2016 1 commit
    • Yorick Peterse's avatar
      Smarter flushing of branch statistics caches · 2ce0d063
      Yorick Peterse authored
      Instead of flushing the behind/ahead counts for all branches upon every
      push we now only flush the cache of branches that actually need to have
      these statistics recalculated. There are now basically 2 scenarios and
      their effects:
      1. A user pushes a commit to the default branch, this results in the
         cache being flushed for all branches.
      2. A user pushes to a non default branch, this results in _only_ the
         cache for that branch being flushed.
      The existing code (Repository#expire_cache) remains backwards compatible
      with the previous behaviour, the new behaviour is only applied when a
      branch name is passed as an argument. This ensures that when for example
      a project is deleted the cache for all branches is flushed.
  7. 08 Feb, 2016 2 commits
    • Yorick Peterse's avatar
      Cache various Repository Git operations · 9a99d8e4
      Yorick Peterse authored
      This caches the output of the following methods:
      * Repository#empty?
      * Repository#has_visible_content?
      * Repository#root_ref
      The cache for Repository#has_visible_content? is flushed whenever a
      commit is pushed to a new branch or an existing branch is removed.
      The cache for Repository#root_ref is only flushed whenever a user
      changes the default branch of a project. The cache for Repository#empty?
      is never explicitly flushed as there's no need for it.
    • Tony Chu's avatar
  8. 04 Feb, 2016 1 commit
    • Yorick Peterse's avatar
      Dedicated method for counting commits between refs · b263ab61
      Yorick Peterse authored
      gitlab_git 8.1 adds the ability to count the amount of commits between
      two references without having to allocate anything but regular
      Rugged::Commit objects. This in turn speeds up the process of counting
      the number of commits a branch is ahead/behind by about 3.5x.
  9. 28 Jan, 2016 1 commit
  10. 22 Jan, 2016 1 commit
  11. 21 Jan, 2016 1 commit
  12. 07 Jan, 2016 3 commits
  13. 25 Dec, 2015 1 commit
    • 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
  14. 18 Dec, 2015 1 commit
  15. 15 Dec, 2015 1 commit
    • Jeff Stubler's avatar
      Fix diverging commit count calculation · 2e8ec7e7
      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.
  16. 10 Dec, 2015 1 commit
  17. 08 Dec, 2015 1 commit
  18. 07 Dec, 2015 1 commit
  19. 03 Dec, 2015 1 commit
  20. 30 Nov, 2015 1 commit
  21. 18 Nov, 2015 3 commits
  22. 16 Nov, 2015 1 commit
  23. 11 Nov, 2015 1 commit
  24. 03 Nov, 2015 1 commit
  25. 02 Nov, 2015 1 commit
  26. 01 Nov, 2015 1 commit
  27. 29 Oct, 2015 4 commits
  28. 28 Oct, 2015 1 commit
  29. 23 Oct, 2015 1 commit