- 08 12月, 2016 5 次提交
-
-
由 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 次提交
-
-
由 Lin Jen-Shin 提交于
Add back check if we're losing commits in a merge.
-
由 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
-
- 03 12月, 2016 1 次提交
-
-
由 mattl 提交于
-
- 02 12月, 2016 9 次提交
-
-
由 Filipa Lacerda 提交于
-
由 Filipa Lacerda 提交于
-
由 Filipa Lacerda 提交于
-
由 Sam Rose 提交于
-
由 winniehell 提交于
-
由 tauriedavis 提交于
-
由 Annabel Dunstone Gray 提交于
-
由 Annabel Dunstone Gray 提交于
-
由 Ryan Harris 提交于
-
- 01 12月, 2016 19 次提交
-
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Yorick Peterse 提交于
By passing commit data to this worker we remove the need for querying the Git repository for every job. This in turn reduces the time spent processing each job. The migration included migrates jobs from the old format to the new format. For this to work properly it requires downtime as otherwise workers may start producing errors until they're using a newer version of the worker code.
-
由 Sean McGivern 提交于
-
由 Sean McGivern 提交于
Instead of doing n queries for n states, do one query to get all the counts grouped by state, and figure out what the count is for each state is from that. We can still cache the individual counts (it can't hurt), but this will help with initial load. Note that the `opened` scope on `Issuable` includes the `opened` and `reopened` states, which is why there's a special case.
-
由 Sean McGivern 提交于
`any?` on an AR relation performs a `SELECT COUNT`, which we don't need. 1. We are very likely to have issues or MRs, so the `SELECT COUNT` is often unnecessary. 2. Even where there are no items returned, the overhead of the `SELECT *` instead of `SELECT COUNT` is relatively small. Calling `to_a` on the relation lets us use `Enumerable#any?`, which will return immediately if there are objects returned.
-
由 Andrew Smith 提交于
-
由 Adam Niedzielski 提交于
when we care only about the number of commits We do not have to instantiate all objects in this case.
-
由 Adam Niedzielski 提交于
The implicit interface of project services states that the "execute" method is meant to be called when project hooks are executed. Currently JiraService does not support any project events even though JiraService#supported_events says that "commit" and "merge_request" are supported. They are only used to render correct options in JIRA configuration screen, but they are not supported. Because of that, this commit makes "execute" method a no-op.
-
由 Mike Greiling 提交于
-
由 Mike Greiling 提交于
-
由 Mike Greiling 提交于
-
由 Mike Greiling 提交于
-
由 Mike Greiling 提交于
-
由 Mike Greiling 提交于
-
由 Mike Greiling 提交于
-
由 Mike Greiling 提交于
-
由 Mike Greiling 提交于
-
由 Mike Greiling 提交于
-
由 Mike Greiling 提交于
-