- 07 1月, 2016 1 次提交
-
-
由 koreamic 提交于
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
-
- 25 12月, 2015 1 次提交
-
-
由 Stan Hu 提交于
`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
-
- 18 12月, 2015 1 次提交
-
-
由 Douwe Maan 提交于
-
- 16 12月, 2015 1 次提交
-
-
由 Jeff Stubler 提交于
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.
-
- 10 12月, 2015 1 次提交
-
-
由 Zeger-Jan van de Weg 提交于
-
- 08 12月, 2015 2 次提交
-
-
由 Douwe Maan 提交于
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 03 12月, 2015 1 次提交
-
-
由 Rubén Dávila 提交于
-
- 01 12月, 2015 1 次提交
-
-
由 Valery Sizov 提交于
-
- 18 11月, 2015 3 次提交
-
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
- 16 11月, 2015 1 次提交
-
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 12 11月, 2015 1 次提交
-
-
由 Jeff Stubler 提交于
-
- 04 11月, 2015 1 次提交
-
-
由 Robert Speicher 提交于
Closes #3311
-
- 02 11月, 2015 2 次提交
-
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
由 Jeff Stubler 提交于
-
- 29 10月, 2015 5 次提交
-
-
由 Michael Chmielewski 提交于
-
由 Michael Chmielewski 提交于
Fixed method to use git log via Popen as recommended, and made output match test (and thus system) expectations.
-
由 Michael Chmielewski 提交于
-
由 Jonathan Schoeffling 提交于
Include the log messages of recent commits in project-level search results, providing functionality similar to 'git log --grep'. Update repository model rspec tests to validate the output of Repository#commits_with_log_matching.
-
由 Stan Hu 提交于
Closes #3138
-
- 23 10月, 2015 2 次提交
-
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 21 10月, 2015 2 次提交
-
-
由 Dirceu Pereira Tiegs 提交于
-
由 Artem V. Navrotskiy 提交于
-
- 20 10月, 2015 2 次提交
-
-
由 Jacob Vosmaer 提交于
-
由 Douwe Maan 提交于
-
- 16 10月, 2015 2 次提交
-
-
由 Stan Hu 提交于
-
由 Zeger-Jan van de Weg 提交于
-
- 14 10月, 2015 2 次提交
-
-
由 Zeger-Jan van de Weg 提交于
-
由 Zeger-Jan van de Weg 提交于
Fixes #2526
-
- 07 10月, 2015 1 次提交
-
-
由 Stan Hu 提交于
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
-
- 03 10月, 2015 1 次提交
-
-
由 Guilherme Garnier 提交于
-
- 17 8月, 2015 2 次提交
-
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 14 8月, 2015 3 次提交
-
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
由 Dmitriy Zaporozhets 提交于
-
由 Stan Hu 提交于
Closes #2272
-
- 13 8月, 2015 1 次提交
-
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-