| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`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.
|
|
98f147e84d2bd8f2278452ac0852118452c76d4a fixed this for issues in HTML,
but not MRs or Atom feeds.
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
Make the following changes to deal with new behavior in Rails 4.1.2:
* Use nested resources to avoid slashes in arguments to path helpers.
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
I've changed all the instances of "Nothing to show here" to specifically mention
the name of the entity of which there are none to show. This makes for a
slightly smoother reading experience.
|
|
Conflicts:
app/contexts/filter_context.rb
app/contexts/search_context.rb
app/models/merge_request.rb
app/models/note.rb
app/views/shared/_merge_requests.html.haml
spec/controllers/commit_controller_spec.rb
spec/services/notification_service_spec.rb
|
|
|
|
|
|
The good:
- You can do a merge request for a forked commit and it will merge properly (i.e. it does work).
- Push events take into account merge requests on forked projects
- Tests around merge_actions now present, spinach, and other rspec tests
- Satellites now clean themselves up rather then recreate
The questionable:
- Events only know about target projects
- Project's merge requests only hold on to MR's where they are the target
- All operations performed in the satellite
The bad:
- Duplication between project's repositories and satellites (e.g. commits_between)
(for reference: http://feedback.gitlab.com/forums/176466-general/suggestions/3456722-merge-requests-between-projects-repos)
Fixes:
Make test repos/satellites only create when needed
-Spinach/Rspec now only initialize test directory, and setup stubs (things that are relatively cheap)
-project_with_code, source_project_with_code, and target_project_with_code now create/destroy their repos individually
-fixed remote removal
-How to merge renders properly
-Update emails to show project/branches
-Edit MR doesn't set target branch
-Fix some failures on editing/creating merge requests, added a test
-Added back a test around merge request observer
-Clean up project_transfer_spec, Remove duplicate enable/disable observers
-Ensure satellite lock files are cleaned up, Attempted to add some testing around these as well
-Signifant speed ups for tests
-Update formatting ordering in notes_on_merge_requests
-Remove wiki schema update
Fixes for search/search results
-Search results was using by_project for a list of projects, updated this to use in_projects
-updated search results to reference the correct (target) project
-udpated search results to print both sides of the merge request
Change-Id: I19407990a0950945cc95d62089cbcc6262dab1a8
|
|
|
|
|
|
|
|
group
|
