An error occurred fetching the project authors.
- 08 Jan, 2016 2 commits
-
-
Robert Schilling authored
-
Stan Hu authored
[ci skip]
-
- 07 Jan, 2016 7 commits
-
-
Douwe Maan authored
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Douwe Maan authored
-
Jacob Vosmaer authored
-
Douwe Maan authored
-
koreamic authored
Using the fuzzy filter, develop "file finder" feature. - feedback(http://feedback.gitlab.com/forums/176466-general/suggestions/4987909-add-file-finder-fuzzy-input-in-files-tab-to-ju ) - fuzzy filter(https://github.com/jeancroy/fuzzaldrin-plus) - shortcuts(when "t" was hitted at tree view, go to 'file find' page and 'esc' is to go back) - depends on gitlab_git 7.2.22
-
Stan Hu authored
Closes #3635, #1383
-
- 06 Jan, 2016 1 commit
-
-
Janis Meybohm authored
-
- 05 Jan, 2016 5 commits
-
-
Robert Speicher authored
-
Michi302 authored
-
Douglas Barbosa Alexandre authored
-
Douwe Maan authored
Get "Merge when build succeeds" to work when commits were pushed to MR target branch while builds were running
-
Douglas Barbosa Alexandre authored
-
- 04 Jan, 2016 4 commits
-
-
Stan Hu authored
Closes #4708
-
Robert Speicher authored
[ci skip]
-
Steve Norman authored
-
Douglas Barbosa Alexandre authored
-
- 03 Jan, 2016 3 commits
-
-
Josh Frye authored
-
Stan Hu authored
Attempting to use the /projects/:id API by specifying :id in "namespace/project" format would always result in a 404 if the namespace contained a dot. The reason? From http://guides.rubyonrails.org/routing.html#specifying-constraints: "By default the :id parameter doesn't accept dots - this is because the dot is used as a separator for formatted routes. If you need to use a dot within an :id add a constraint which overrides this - for example id: /[^\/]+/ allows anything except a slash." Closes https://github.com/gitlabhq/gitlabhq/issues/9573
-
Stan Hu authored
Closes #5728
-
- 01 Jan, 2016 1 commit
-
-
Robert Speicher authored
While Safari supports the policy, it does not (currently, as of 9.x) recognize `origin-when-cross-origin` as a valid value, so we omit the policy entirely under Safari. Closes #5609
-
- 31 Dec, 2015 1 commit
-
-
Robert Speicher authored
[ci skip]
-
- 30 Dec, 2015 3 commits
-
-
Robert Speicher authored
[ci skip]
-
Zeger-Jan van de Weg authored
Closes #4039
-
Robert Speicher authored
[ci skip]
-
- 29 Dec, 2015 2 commits
-
-
Robert Speicher authored
[ci skip]
- 27 Dec, 2015 1 commit
-
-
Stan Hu authored
-
- 25 Dec, 2015 2 commits
-
-
Valery Sizov authored
-
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
-
- 24 Dec, 2015 8 commits
-
-
Gabriel Mazetto authored
-
Stan Hu authored
Closes #4295
-
Robert Speicher authored
[ci skip]
-
Stan Hu authored
Needed to support Huboard
-
Valery Sizov authored
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-