- 15 11月, 2016 4 次提交
-
-
由 Lin Jen-Shin 提交于
-
由 Lin Jen-Shin 提交于
-
由 Lin Jen-Shin 提交于
If `source_branch` option is passed, and target branch cannot be found, `Repository#update_branch_with_hooks` would try to create a new branch from `source_branch`. This way, we could make changes in the new branch while only firing the hooks once for the changes. Previously, we can only create a new branch first then make changes to the new branch, firing hooks twice. This behaviour is bad for CI. Fixes #7237
-
由 Lin Jen-Shin 提交于
This reverts commit a431ca0f.
-
- 10 11月, 2016 3 次提交
-
-
由 teru 提交于
-
由 Grzegorz Bizon 提交于
-
由 Grzegorz Bizon 提交于
-
- 08 11月, 2016 1 次提交
-
-
由 Valery Sizov 提交于
-
- 07 11月, 2016 1 次提交
-
-
由 Grzegorz Bizon 提交于
-
- 02 11月, 2016 1 次提交
-
-
由 Kamil Trzcinski 提交于
Currently, our procedure for adding a commit requires us to execute `CreateBranchService` before file creation. It's OK, but also we do execute `git hooks` (the `PostReceive` sidekiq job) as part of this process. However, this hook is execute before the file is actually committed, so the ref is updated. Secondly, we do execute a `git hooks` after committing file and updating ref. This results in duplicate `PostReceive` jobs, where the first one is completely invalid. This change makes the branch creation, something that is intermediate step of bigger process (file creation or update, commit cherry pick or revert) to not execute git hooks.
-
- 29 10月, 2016 1 次提交
-
-
由 Alejandro Rodríguez 提交于
When we updated gitlab_git to 10.4.1, `tag.target` changed from pointing to the sha of the tag to the sha of the commit the tag points to. The problem is that only annotated tags have `object_sha`s, lightweight tags don't (it's nil), so (only) in their case we still need to use `tag.target`.
-
- 28 10月, 2016 1 次提交
-
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 24 10月, 2016 2 次提交
- 20 10月, 2016 1 次提交
-
-
由 Valery Sizov 提交于
-
- 14 10月, 2016 2 次提交
-
-
由 Z.J. van de Weg 提交于
-
由 Z.J. van de Weg 提交于
-
- 11 10月, 2016 1 次提交
-
-
由 tiagonbotelho 提交于
-
- 10 10月, 2016 2 次提交
-
-
由 Adam Niedzielski 提交于
Fixes #21800.
-
由 tiagonbotelho 提交于
removes inconsistency regarding tagging immediately as merged once you create a branch using new branch button and adds changelog entry
-
- 06 10月, 2016 1 次提交
-
-
由 Marc Siegfriedt 提交于
add docs and tests - add additional validation allow move without content updated response
-
- 04 10月, 2016 1 次提交
-
-
由 Z.J. van de Weg 提交于
-
- 21 9月, 2016 1 次提交
-
-
由 Dan Dunckel 提交于
-
- 20 9月, 2016 1 次提交
-
-
由 Dan Dunckel 提交于
-
- 14 9月, 2016 1 次提交
-
-
由 Valery Sizov 提交于
-
- 13 9月, 2016 1 次提交
-
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
- 10 9月, 2016 1 次提交
-
-
由 tiagonbotelho 提交于
refactors update file
-
- 07 9月, 2016 2 次提交
-
-
由 Jacob Vosmaer 提交于
-
由 Jacob Vosmaer 提交于
-
- 02 9月, 2016 2 次提交
-
-
由 Jacob Vosmaer 提交于
-
由 Jacob Vosmaer 提交于
-
- 01 9月, 2016 1 次提交
-
-
由 Stan Hu 提交于
If `git gc` runs and `Repository` has an instance to `Rugged::Repository`, a bug in libgit2 may cause the instance to return a stale value or a missing branch. This change not only optimizes the branch lookup so we don't have to iterate through every branch, but it also works around the `git gc` issue by forcing a repository reload every time `Repository#find_branch` is called. See: https://github.com/libgit2/libgit2/issues/1534 Closes #15392, #21470
-
- 25 8月, 2016 1 次提交
-
-
由 Hannes Rosenögger 提交于
This commit makes sure that the project icon is being read from the default branch instead of 'master'
-
- 20 8月, 2016 1 次提交
-
-
由 Gokmen Goksel 提交于
Koding: #index: landing page for Koding integration If enabled it will provide a link to open remote Koding instance url for now we are also providing the sneak preview video for how integration works in detail. Repository: check whether .koding.yml file exists on repository Projects: landing page: show Run in IDE (Koding) button if repo has stack file Projects: MR: show Run in IDE Koding button if repo has stack file on active branch ProjectHelpers: add_koding_stack: stack generator for provided project With this helper we will auto-generate the required stack template for a given project. For the feature we can request this base template from the running Koding instance on integration. Currently this will provide users to create a t2.nano instance on aws and it'll automatically configures the instance for basic requirements. Projects: empty state and landing page provide shortcuts to create stack projects_helper: use branch on checkout and provide an entry point This ${var.koding_queryString_branch} will be replaced with the branch provided in query string which will allow us to use same stack template for different branches of the same repository. ref: https://github.com/koding/koding/pull/8597/commits/b8c0e43c4c24bf132670aa8a3cfb0d634acfd09b projects_helper: provide sha info in query string to use existing vms With this change we'll be able to query existing vms on Koding side based on the commit id that they've created. ref: https://github.com/koding/koding/pull/8597/commits/1d630fadf31963fa6ccd3bed92e526761a30a343 Integration: Docs: Koding documentation added Disable /koding route if integration is disabled Use application settings to enable Koding Projects_helper: better indentation with strip_heredoc usage Projects_helper: return koding_url as is if there is no project provided current_settings: set koding_enabled: false by default Koding_Controller: to render not_found once integration is disabled Dashboard_specs: update spec for Koding enabled case Projects_Helper: make repo dynamic ref: https://github.com/koding/koding/pull/8597/commits/4d615242f45aaea4c4986be84ecc612b0bb1514c Updated documentation to have right format
-
- 17 8月, 2016 1 次提交
-
-
由 Yorick Peterse 提交于
GitLab Performance Monitoring is now able to track custom events not directly related to application performance. These events include the number of tags pushed, repositories created, builds registered, etc. The use of these events is to get a better overview of how a GitLab instance is used and how that may affect performance. For example, a large number of Git pushes may have a negative impact on the underlying storage engine. Events are stored in the "events" measurement and are not prefixed with "rails_" or "sidekiq_", this makes it easier to query events with the same name triggered from different parts of the application. All events being stored in the same measurement also makes it easier to downsample data. Currently the following events are tracked: * Creating repositories * Removing repositories * Changing the default branch of a repository * Pushing a new tag * Removing an existing tag * Pushing a commit (along with the branch being pushed to) * Pushing a new branch * Removing an existing branch * Importing a repository (along with the URL we're importing) * Forking a repository (along with the source/target path) * CI builds registered (and when no build could be found) * CI builds being updated * Rails and Sidekiq exceptions Fixes gitlab-org/gitlab-ce#13720
-
- 13 8月, 2016 1 次提交
-
-
由 Sean McGivern 提交于
-
- 09 8月, 2016 1 次提交
-
-
由 Alejandro Rodríguez 提交于
-
- 06 8月, 2016 1 次提交
-
-
由 Gabriel Mazetto 提交于
-
- 04 8月, 2016 1 次提交
-
-
由 Stan Hu 提交于
-
- 03 8月, 2016 1 次提交
-
-
由 Paco Guzman 提交于
So we have raw_diffs too
-