| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| | |
fixies #19747
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Allow build email service to be tested
Fixes #13343
See merge request !5223
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Collapsed diffs lines/size don't accumulate to overflow diffs.
## What does this MR do?
Reduce the number of lines that we highlight on big diffs to try to reduce the degradation introduced by !4990 as you can see on the issue description #19820 .
We collapse any files after the diff is over the number of safe files (100), or over the safe lines (500) or over the safe number of bytes (5KB x 100 files).
We still need to bump the gitlab_git and point this branch to the new gitlab_git version.
## What are the relevant issue numbers?
Closes #19820
Closes #19885
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- ~~[ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- ~~[ ] API support added~~
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5306
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Revert "Revert "Merge branch '18193-developers-can-merge' into 'master'""
## What does this MR do?
Reverts the revert of !4892 which lacked an EE MR at the time. This has been done in gitlab-org/gitlab-ee!564.
## What are the relevant issue numbers?
Closes #19872.
See merge request !5310
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 530f5158e297f3cde27f3566cfe13bad74ba3b50.
See !4892.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| | |
Add Pending Tab to Project Builds
Update CHANGELOG
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Allow U2F devices to be used in Firefox
- Adds U2F support for Firefox
- Improve U2F feature detection logic
- Have authentication flow be closer to the spec (single challenge instead of a challenge for each `signRequest`)
- Closes #17341
- Related to #15337
See merge request !5177
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. According to the spec, either we have a single challenge with
a number of `signRequests`, or a number of `signRequests`, each with
it's own challenge.
2. Previously, we had both these - per-request challenges, as well as a
single extra challenge.
3. This commit changes this so that the per-request challenges are
removed, leaving only a single challenge, as per the v1.1 U2F API.
4. The existing implementation didn't work in Firefox, because the
Firefox (extension) implementation is less flexible with regard to
the inputs.
5. Fix teaspoon specs.
6. References: https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#h2_background
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. Only on supported Chrome versions
2. Mainly, this lets us simplify the javascript-based U2F check to
`window.u2f`, where `window.u2f` can either be loaded from the GitLab
server (for Chrome) or from the Firefox extension.
3. This is a better way to provide browser detection for U2F.
|
| | |/
|/|
| |
| | |
This reverts commit c39356998b1850f3dc26fe0b987cb419c1d1afb4.
|
| | |
| |
| |
| |
| | |
This reverts commit 9ca633eb4c62231e4ddff5466c723cf8e2bdb25d, reversing
changes made to fb229bbf7970ba908962b837b270adf56f14098f.
|
| | |
| |
| |
| |
| | |
- Cherry-picked from `mvestergaard:branch-protection-dev-merge`
- https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add 2FA check to the OAuth authentication mechanism
Needed for https://gitlab.com/gitlab-org/gitlab-ce/issues/19312
2FA checks were not being performed when logging in via any of the OAuth providers. Just LDAP had the check. This MR fixes that.
See merge request !1976
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Optimistic locking for Issue and Merge Requests
## What does this MR do?
It implements Optimistic Locking http://api.rubyonrails.org/classes/ActiveRecord/Locking/Optimistic.html for Issues and MRs but in a bit custom way. We use it for cases when either title or description field is involved in the change.
## Why was this MR needed?
We have to prevent data losing.
## What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ce/issues/12940
## Screenshots (if relevant)
See merge request !5146
|
| | | | | |
|
| |/ / / |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
parameters.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Single file diffs
Closes #14103. Related (not part of this MR): #19553.
This adds a `diff_for_path` action to each place we render diffs (commit, compare, new MR, existing MR) which renders the diff for a single path. The action is always available with the same params as the 'parent' action, to make it simpler to generate the URIs.
If a diff is bigger than 10 KB, it will be collapsed by default and have a data attribute added. You can then click the message or the filename to expand that diff. For expanded files, you can collapse and expand them, but they won't make any AJAX requests.
See merge request !4990
|
| | | | | |
|
| | |\ \ \
| | | |/
| | |/| |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1. Move render method to a concern, not a helper.
2. Let DiffHelper#diff_options automatically add the path option.
3. Move more instance var definitions to before filters.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
When rendering a list of diff files, skip those where the diff is over
10 KB and provide an endpoint to render individually instead.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use Gitlab-Workhorse-Send-Data to send entry
## What does this MR do?
Use Gitlab-Workhorse-Send-Data to send entry:
Closes #19224, Closes #19128
Also requires this MR to work:
https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/53
## Are there points in the code the reviewer needs to double check?
Do we have a test for this?
## Why was this MR needed?
This way gitlab-workhorse does not have to call any API.
See merge request !5094
|
| | | | |
| | | |
| | | |
| | | | |
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5094#note_12984211
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Closes #19224, Closes #19128
Also requires this MR to work:
https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/53
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Enable Style/IdenticalConditionalBranches Rubocop cop
## What does this MR do?
This MR enables Rubocop cop that checks for identical lines at the end of each branch of a conditional statement.
Examples:
```ruby
@bad
if condition
do_x
do_z
else
do_y
do_z
end
@good
if condition
do_x
else
do_y
end
do_z
```
## What are the relevant issue numbers?
#17478
See merge request !5011
|
| | | |/ /
| |/| | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Avoid calculation of closes_issues.
## What does this MR do?
Avoid unneeded calls to MR closes issues
## Are there points in the code the reviewer needs to double check?
I'm not sure if calling this method from a view is a good practice, but I cannot see another simple way of avoiding this problem. In case we want to avoid this in the controller we need to specify the action, format and status of the merge request, because in that case we know that the `_open` partial will render. We could add some lazy evaluation but it not a thing I see in use along the app but feedback is welcome
## What are the relevant issue numbers?
#14202 , #19490
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- ~~[ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- ~~[ ] API support added~~
- Tests
- ~~[ ] Added for this feature/bug~~
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5140
|
| | | | | |
| | | | |
| | | | |
| | | | | |
We just need to get merge requests closes issues when
we’re going to show them
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Added setting to set new users by default as external
## What does this MR do?
This implements the feature request #14508. It adds an option in the application settings to set new users by default as external.
## Are there points in the code the reviewer needs to double check?
Everything. Like I mentioned in the discussion of the issue my knowledge of Ruby basically doesn't exists. I tested it on my machine and it seems to work, but as I am very unexperienced in Ruby I highly recommend to take a close look at the code.
## Why was this MR needed?
It was requested by @DouweM to work on the issue with the proposed changes by me.
## What are the relevant issue numbers?
This MR is for the issue #14508 that followed up after the implementation of #4009.
See merge request !4545
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As requested by the issue #14508 this adds an option in the application
settings to set newly registered users by default as external. The
default setting is set to false to stay backward compatible.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This reverts commit bf2a86b73cce332ff8f4392ffc8df501193f32ec.
|
| |\ \ \ \ \ |
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Allow specifying protected branches using wildcards
Closes #18627
# Tasks
- [ ] #18627 !4665 Allow specifying protected branches using wildcards
- [x] Find existing usages of protected branches
- Protecting branches
- `ProtectedBranchesController` is used to mark a branch protected/unprotected
- `API::Branches` can be used to mark a branch protected/unprotected
- Enforcing branch protection
- `Gitlab::GitAccess` has helpers (`can_push_to_branch?`, `check`) that are used to deny pushes if a branch is protected
- Over SSH: `gitlab-shell` receives a push, and calls `/allowed` on the GitLab API, which calls `GitAccess.check`
- Over HTTP:
- `gitlab-workhorse` receives the request, and forwards it to rails
- Rails (in the `GitHttpController#git-recieve-pack`) runs basic checks (is the user logged in, not protected branch checks) and returns ok with `GL_ID` and `RepoPath`
- `gitlab-workhorse` looks at the response, and calls the relevant `gitlab-shell` action from `git-http/handlePostRPC`
- Rest of this flow is the same as the SSH flow above
- [x] Implementation
- [x] Backend
- [x] Change `project#protected_branch?` to look at wildcard protected branches
- [x] Change `project#developers_can_push_to_protected_branch?`
- [x] Change `project#open_branches`
- [x] Better error message when creating a disallowed branch from the Web UI
- [x] Frontend
- [x] Protected branches page should allow typing out a wildcard pattern
- [x] Add help text explaining the use of wildcards
- [x] Show matching branches for each protected branch
- [x] ~~On the index page~~
- [x] On a show page
- [x] Index?
- [x] Can't have the "last commit" column for wildcard protected branches
- [x] Fix / write tests
- [x] What happens if a hook is missing in dev?
- [x] Refactor
- [x] Test workflows
- Create a branch matching a wildcard pattern
- Push to a branch matching a wildcard pattern
- Force push to a branch matching a wildcard pattern
- Delete a branch matching a wildcard pattern
- [x] Test using Web UI
- [x] Test over SSH
- [x] Test over HTTP
- [x] Test as developer and master
- [x] Investigate performance
- [x] Test with a large number of protected branches / branches
- [x] Paginate list of protected branches
- [x] ~~Possibly rewrite `open_branches`~~
- [x] Add `iid`s to existing `ProtectedBranch`es
- [x] Add documentation
- [x] Add CHANGELOG entry
- [x] Add screenshots
- [x] Make sure [build](https://gitlab.com/gitlab-org/gitlab-ce/commit/2f753e3ed2ce681b4444944d521f4419e8ed37f7/builds) passes
- [x] Assign to endboss for review
- [x] Address @DouweM's comments
- [x] `protected_branch_params`
- [x] `exact_match` instead of `explicit_match`
- [x] When would self.name be blank?
- [x] Move `protected_branches.each` to a partial
- [x] Move `matching_branches.each` to a partial
- [x] If the branch is in @matching_branches, it's not been removed
- [x] move this regex to a method and memoize it
- [x] `commit_sha` directly for exact matches
- [x] Number of matches for wildcard matches, with a link
- [x] Wait for [build](https://gitlab.com/gitlab-org/gitlab-ce/commit/43f9ce0e88194b8f719bb1c1e656b7fc13278d56/builds) to pass
- [x] Respond to @DouweM's comments
- [x] Don't use iid
- [x] Controller should use `@project.protected_branches.new`
- [x] move the memoization to `def wildcard_regex`
- [x] render with `collection: @protected_branches`
- [x] Wait for [build](https://gitlab.com/gitlab-org/gitlab-ce/commit/f7beedf122fa0c7aa89e86181fe7499321fb10ca/builds) to pass
- [x] Wait for @DouweM's review
- [x] Wait for @jschatz1's review
- [x] Respond to @jschatz1's comments
- [x] Use the new dropdown style
- [x] description should be moved to the description section without the styling
- [x] Protect button should be disabled when no branch is selected
- [x] Update screenshots
- [x] Merge conflicts
- [x] Make sure [build](https://gitlab.com/gitlab-org/gitlab-ce/commit/20f3cfe8d5540eab64c2ba548043d600b28c61ba/builds) passes
- [ ] Revisit performance, possibly with staging/production data
- [ ] Get a dump of staging / run against staging live
- [ ] Get SSH access to staging
- [ ] Wait for review/merge
# Screenshots
## Creating wildcard protected branches
### Using the `GLDropdown` component
## Enforcing wildcard protected branches
### From the Web UI
### Over SSH
### Over HTTPS
## Listing matching branches
See merge request !4665
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
1. Modify the component to support a callback for every key press in the
filter. We need this so we can update the "Create: <branch_name"
label.
2. Modify the component to use `$(<selector>).first().click()` instead
of `$(selector)[0].click()`, because the latter is non-standard, and
doesn't work in PhantomJS.
|
| | | | |_|/ /
| | |/| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
1. Allow entering any branch name for a protected branch.
- Either pick from a list of options, or enter it manually
- You can enter wildcards.
2. Display branches matching a protected branch.
- Add a `ProtectedBranches#show` page that displays the branches
matching the given protected branch, or a message if there are no
matches.
- On the `index` page, display the last commit for an exact match,
or the number of matching branches for a wildcard match.
- Add an `iid` column to `protected_branches` - this is what we use for
the `show` page URL.
- On the off chance that this feature is unnecessary, this commit
encapsulates it neatly, so it can be removed without affecting
anything else.
3. Remove the "Last Commit" column from the list of protected branches.
- There's no way to pull these for wildcard protected branches, so it's
best left for the `show` page.
- Rename the `@branches` instance variable to `@protected_branches`
- Minor styling changes with the "Unprotect" button - floated right
like the "Revoke" button for personal access tokens
4. Paginate the list of protected branches.
5. Move the instructions to the left side of the page.
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | | |
This reverts commit 68155ee73b549a4f79744bb325542c29d45c71ea, reversing
changes made to 7ebd011ed1de7aee706f07a53c63c90f1c8aa5d4.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
New diff notes
Fixes #12732, #14731, #19375, #14783
Builds on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4110
To do:
- [x] Get it mostly working
- [x] Validate position validity
- [x] Fix: Don’t link to `#`
- [x] Fix: Base ref can be `nil`, potentially, when the MR has an oprhan source branch => Yep, doesn’t work. We need to store a `start_id`
- [x] Optimize: Fewer duplicate `git diff` compares
- [x] Optimize: Pass paths to `PositionTracer#diff` for faster diffs
- [x] Refactor: Use `head_id` in `MergeRequest`/`MergeRequestDiff` instead of `source_sha`
- [x] Refactor: Convert existing array-based diff refs to the DiffRefs model
- [x] Tweak: Use `note_type` in `Autosave` key
- [x] Tweak: Remove `line_code: note.line_code` from `link_to_reply_discussion`
- [x] Update: `SentNotifications` and reply-by-email receiver
- [x] Update: MR diff notification email
- [x] Update: API (MR, Commit note creation and entity)
- [x] Update: GitHub importer
- [x] Address any other TODO comments
- [x] Fix: Suppress "edited 4 minutes ago"
- [x] Write tests
- [x] `LineMapper`
- [x] `PositionTracer`
- [x] `Position`
- [x] `DiffPositionUpdateService`
- [x] `DiffNote`
- [x] `MergeRequests::RefreshService` / `MergeRequest#update_diff_notes_positions`
- [x] Make sure commits with diff notes don't get cleaned up, since this would prevent the diff notes from being rendered (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5062)
Future improvements:
- Display unresolved comments on files outside the diff, if the comment was added when that file _was_ part of the diff
- Allow commenting on sections between hunks, when expanding the diff using `...`
- (We'd need to generate line code based on Position if we have it, even if it falls outside bounds of diff)
- `diff_hunk` on diff note API entity
- Show diff hunk in notification email
- Resolved line notes would have a boolean, and be inactive through `notes.any? { !active? || resolved? }`
- Multi line notes would store a number of positions, and do the right thing (™) in grouping and then rendering if the first item is multiline? => true
- Image diff notes could store x,y,width,height instead of old_line,new_line for similar grouping. Does it need a reference to say if it's on old or new? These can't have line_codes, clearly. Rendering would be interesting.
- Show commit line comments in the MR diff
- Comment on specific selected words
- Comment on file header
- Unfold top of discussion diff note
- New diff notes API for commits and MRs
/cc @rspeicher
See merge request !4101
|
