- 23 2月, 2017 1 次提交
-
-
由 Douwe Maan 提交于
-
- 14 2月, 2017 1 次提交
-
-
由 Douwe Maan 提交于
-
- 07 2月, 2017 5 次提交
-
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
- 03 2月, 2017 1 次提交
-
-
由 Sean McGivern 提交于
Backport changes from the EE-only squash implementation, which would otherwise conflict when merge CE into EE. <https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1024>
-
- 27 1月, 2017 1 次提交
-
-
由 Stan Hu 提交于
In repositories such as https://github.com/git/git.git, annotated tags can point to blobs, not necessarily to commits. `Repository` attempts to return the tags in the order of the commit date, but if a commit is not available the previous implementation would error due to a `nil` target. This change modifies the code to use the current time if a commit is not associated with the given tag. Closes #27228
-
- 26 1月, 2017 1 次提交
-
- 16 1月, 2017 1 次提交
-
-
由 Minqi Pan 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
- 06 1月, 2017 2 次提交
-
-
由 Lin Jen-Shin 提交于
-
由 Lin Jen-Shin 提交于
-
- 05 1月, 2017 3 次提交
-
-
由 Lin Jen-Shin 提交于
-
由 Lin Jen-Shin 提交于
We merge repository checks inside it so we don't have to check it on the call site, and we could also load the commit for the caller. This greatly reduce code duplication. Feedback: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7237#note_20572919
-
由 Lin Jen-Shin 提交于
-
- 20 12月, 2016 3 次提交
-
-
由 Hiroyuki Sato 提交于
-
由 Hiroyuki Sato 提交于
-
由 Hiroyuki Sato 提交于
-
- 14 12月, 2016 1 次提交
- 12 12月, 2016 1 次提交
-
-
由 Lin Jen-Shin 提交于
It's very weird that source_commit.raw_commit and rugged.branches[merge_request.target_branch].target should be completely the same. I checked with == and other values which proved that both should be the same, but still tests cannot pass for: spec/services/merge_requests/refresh_service_spec.rb I decided to give it up. We could just use SHA and that works fine anyway.
-
- 10 12月, 2016 1 次提交
-
-
由 Lin Jen-Shin 提交于
-
- 09 12月, 2016 3 次提交
-
-
由 Douwe Maan 提交于
Replace MR access checks with use of MergeRequestsFinder Split from !2024 to partially solve https://gitlab.com/gitlab-org/gitlab-ce/issues/23867
⚠ - Potentially untested💣 - No test coverage🚥 - Test coverage of some sort exists (a test failed when error raised)🚦 - Test coverage of return value (a test failed when nil used)✅ - Permissions check tested - [x]💣 app/finders/notes_finder.rb:17 - [x]⚠ app/views/layouts/nav/_project.html.haml:80 [`.count`] - [x]💣 app/controllers/concerns/creates_commit.rb:84 - [x]🚥 app/controllers/projects/commits_controller.rb:24 - [x]🚥 app/controllers/projects/compare_controller.rb:56 - [x]🚦 app/controllers/projects/discussions_controller.rb:29 - [x]✅ app/controllers/projects/todos_controller.rb:27 - [x]🚦 app/models/commit.rb:268 - [x]✅ lib/gitlab/search_results.rb:71 - [x] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#d1c10892daedb4d4dd3d4b12b6d071091eea83df_267_266 Memoize ` merged_merge_request(current_user)` - [x] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#d1c10892daedb4d4dd3d4b12b6d071091eea83df_248_247 Expected side effect for `merged_merge_request!`, consider `skip_authorization: true`. - [x] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#d1c10892daedb4d4dd3d4b12b6d071091eea83df_269_269 Scary use of unchecked `merged_merge_request?` See merge request !2033
- 08 12月, 2016 8 次提交
-
-
由 Lin Jen-Shin 提交于
commits from the other repository. We'll cleanup the tmp ref after we're done with our business.
-
由 Lin Jen-Shin 提交于
more consistent across different methodst
-
由 Lin Jen-Shin 提交于
by checking filename as well
-
由 Lin Jen-Shin 提交于
-
由 Lin Jen-Shin 提交于
-
由 Lin Jen-Shin 提交于
-
由 Lin Jen-Shin 提交于
-
由 Lin Jen-Shin 提交于
-
- 07 12月, 2016 4 次提交
-
-
由 Lin Jen-Shin 提交于
have the branch existed upfront. That is, `Rugged::Commit.create` rather than `Gitlab::Git::Blob.commit` which the former doesn't need to have the branch but the latter needs.
-
由 Lin Jen-Shin 提交于
-
由 Lin Jen-Shin 提交于
So we still commit outside the hooks, and only update ref inside the hooks. There are only two exceptions: * Whenever it's adding a tag. We can't add a tag without committing, unfortunately. See !7700 * Whenever source project is in another repository. We'll need to fetch ref otherwise commits can't be made. See the whole discussion starting from: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7237#note_19210942
-
- 06 12月, 2016 2 次提交
-
-
由 Yorick Peterse 提交于
This method already uses the cached method Repository#branch_count so there's no point in also caching has_visible_content?. Fixes gitlab-org/gitlab-ce#25278
-
由 Lin Jen-Shin 提交于
git operation inside GitHooksService. Feedback: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7237#note_19210942 TODO: Fix tests for update_branch_with_hooks
-
- 28 11月, 2016 1 次提交
-
-
由 Adam Niedzielski 提交于
We only know the tag SHA after we create the tag. This means that we pass a different value to the hooks that happen before creating the tag, and a different value to the hooks that happen after creating the tag. This is not an ideal situation, but it is a trade-off we decided to make. For discussion of the alternatives please refer to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7700#note_18982873 "pre-receive" and "update" hooks always get the SHA of the commit that the tag points to. "post-receive" gets the tag SHA if it is an annotated tag or the commit SHA if it is an lightweight tag. Currently we always create annotated tags if UI is used.
-