- 28 Nov, 2017 1 commit
-
-
Sean McGivern authored
If a merge request was created with a branch name that also matched a tag name, we'd generate a comparison to or from the tag respectively, rather than the branch. Merging would still use the branch, of course. To avoid this, ensure that when we get the branch heads, we prepend the reference prefix for branches, which will ensure that we generate the correct comparison.
-
- 23 Nov, 2017 1 commit
-
-
Sean McGivern authored
Compared to the merge_request_diff association: 1. It's simpler to query. The query uses a foreign key to the merge_request_diffs table, so no ordering is necessary. 2. It's faster for preloading. The merge_request_diff association has to load every diff for the MRs in the set, then discard all but the most recent for each. This association means that Rails can just query for N diffs from N MRs. 3. It's more complicated to update. This is a bidirectional foreign key, so we need to update two tables when adding a diff record. This also means we need to handle this as a special case when importing a GitLab project. There is some juggling with this association in the merge request model: * `MergeRequest#latest_merge_request_diff` is _always_ the latest diff. * `MergeRequest#merge_request_diff` reuses `MergeRequest#latest_merge_request_diff` unless: * Arguments are passed. These are typically to force-reload the association. * It doesn't exist. That means we might be trying to implicitly create a diff. This only seems to happen in specs. * The association is already loaded. This is important for the reasons explained in the comment, which I'll reiterate here: if we a) load a non-latest diff, then b) get its `merge_request`, then c) get that MR's `merge_request_diff`, we should get the diff we loaded in c), even though that's not the latest diff. Basically, `MergeRequest#merge_request_diff` is the latest diff in most cases, but not quite all.
-
- 13 Nov, 2017 1 commit
-
-
George Andrinopoulos authored
-
- 11 Nov, 2017 1 commit
-
-
George Andrinopoulos authored
-
- 06 Nov, 2017 1 commit
-
-
micael.bergeron authored
-
- 03 Nov, 2017 1 commit
-
-
micael.bergeron authored
also, I refactored the MergeRequest#fetch_ref method to express the side-effect that this method has. MergeRequest#fetch_ref -> MergeRequest#fetch_ref! Repository#fetch_source_branch -> Repository#fetch_source_branch!
-
- 27 Oct, 2017 2 commits
-
-
Oswaldo Ferreira authored
-
Zeger-Jan van de Weg authored
Now, when requesting a commit from the Repository model, the results are not cached. This means we're fetching the same commit by oid multiple times during the same request. To prevent us from doing this, we now cache results. Caching is done only based on object id (aka SHA). Given we cache on the Repository model, results are scoped to the associated project, eventhough the change of two repositories having the same oids for different commits is small.
-
- 13 Oct, 2017 1 commit
-
-
Oswaldo Ferreira authored
-
- 11 Oct, 2017 1 commit
-
-
Oswaldo Ferreira authored
-
- 09 Oct, 2017 2 commits
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 07 Oct, 2017 2 commits
-
-
Bob Van Landuyt authored
The helper creates a fork of a project with all provided attributes, but skipping the creation of the repository on disk.
-
Bob Van Landuyt authored
-
- 04 Oct, 2017 1 commit
-
-
Oswaldo Ferreira authored
-
- 06 Sep, 2017 1 commit
-
-
Sean McGivern authored
-
- 31 Aug, 2017 1 commit
-
-
Felipe Artur authored
-
- 30 Aug, 2017 1 commit
-
-
Yorick Peterse authored
This ensures the issues/MR cache of the sidebar is only updated when the state or confidential flags changes, instead of changing this for every update.
-
- 28 Aug, 2017 2 commits
-
-
Oswaldo Ferreira authored
-
Oswaldo Ferreira authored
-
- 23 Aug, 2017 1 commit
-
-
Yorick Peterse authored
Every project page displays a navigation menu that in turn displays the number of open issues and merge requests. This means that for every project page we run two COUNT(*) queries, each taking up roughly 30 milliseconds on GitLab.com. By caching these numbers and refreshing them whenever necessary we can reduce loading times of all these pages by up to roughly 60 milliseconds. The number of open issues does not include confidential issues. This is a trade-off to keep the code simple and to ensure refreshing the data only needs 2 COUNT(*) queries instead of 3. A downside is that if a project only has 5 confidential issues the counter will be set to 0. Because we now have 3 similar counting service classes the code previously used in Projects::ForksCountService has mostly been moved to Projects::CountService, which in turn is reused by the various service classes. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36622
-
- 13 Aug, 2017 1 commit
-
-
haseeb authored
-
- 10 Aug, 2017 1 commit
-
-
Robert Speicher authored
-
- 09 Aug, 2017 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 07 Aug, 2017 1 commit
-
-
Oswaldo Ferreira authored
-
- 02 Aug, 2017 1 commit
-
-
Robert Speicher authored
-
- 01 Aug, 2017 1 commit
-
-
Gabriel Mazetto authored
-
- 27 Jul, 2017 1 commit
-
-
Rémy Coutable authored
Remove superfluous lib: true, type: redis, service: true, models: true, services: true, no_db: true, api: true Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 24 Jul, 2017 1 commit
-
-
Jarka Kadlecova authored
-
- 07 Jul, 2017 1 commit
-
-
Sean McGivern authored
For merge requests created after 9.4, we have a `merge_request_diff_commits` table we can get all the SHAs from very quickly. We just need to exclude these when we load from the legacy format, by ignoring diffs with no serialised commits. Once these have been migrated in the background, every MR will see this improvement.
-
- 06 Jul, 2017 2 commits
-
-
Sean McGivern authored
This is an ID-less table with just three columns: an association to the merge request diff the commit belongs to, the relative order of the commit within the merge request diff, and the commit SHA itself. Previously we stored much more information about the commits, so that we could display them even when they were deleted from the repo. Since 8.0, we ensure that those commits are kept around for as long as the target repo itself is, so we don't need to duplicate that data in the database.
-
Yorick Peterse authored
This removes the need for relying on Rails' "dependent" option for data removal, which is _incredibly_ slow (even when using :delete_all) when deleting large amounts of data. This also ensures data consistency is enforced on DB level and not on application level (something Rails is really bad at). This commit also includes various migrations to add foreign keys to tables that eventually point to "projects" to ensure no rows get orphaned upon removing a project.
-
- 26 Jun, 2017 1 commit
-
-
Adam Niedzielski authored
Closes #34052
-
- 21 Jun, 2017 1 commit
-
-
Grzegorz Bizon authored
-
- 20 Jun, 2017 1 commit
-
-
Toon Claes authored
To make it simpler to assign users to an Issuable, make MergeRequest support the attribute `assignee_ids`.
-
- 15 Jun, 2017 1 commit
-
-
Eric Eastwood authored
Fix https://gitlab.com/gitlab-org/gitlab-ce/issues/27070 Deprecate "chat commands" in favor of "slash commands" We looked for things like: - `slash commmand` - `slash_command` - `slash-command` - `SlashCommand`
-
- 14 Jun, 2017 1 commit
-
-
Robert Speicher authored
-
- 31 May, 2017 1 commit
-
-
Douwe Maan authored
-
- 29 May, 2017 1 commit
-
-
Douwe Maan authored
-
- 23 May, 2017 1 commit
-
-
Douwe Maan authored
-