Added discard button to comment form
Also changed the labels on the buttons to better match the action they are completing.
Closes#8057
See merge request !3085
Commit limits
Prevent timeouts when creating/viewing Merge Requests with many
commits. Also, reduce the number of commits shown in the UI from 500
to 100.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/14031
This MR avoids Unicorn timeouts in some places and takes 4.5 seconds
off load times in others, when manually testing with a 4500-commit
compare/MR in the linux repo. It does not limit the number of Commit
objects instantiated in memory, just the amount of HTML generated. It
seems that having 4500 commits objects is not a problem in itself. If
it ever becomes one we could do something for Commit objects like we
did for Diff (introduce a CommitCollection or something).
See merge request !3095
The methods used for this are Repository#tag_count and
Repository#branch_count which cache their output in Redis as well as
memoizing it in an instance variable. Both methods have a corresponding
methods/hooks to flush the caches at the right time.
Set cache headers for raw blobs
This changes allows browsers and (in the case of public projects)
proxy caches to cache raw Git blob responses.
See merge request !3113
Indicate when an MR diverged from the target branch
This adds an indicator to the "Merge MR" box, to tell if and how much an MR diverged from its target branch.
For instance, consider an MR to merge the branch `feature` into `master`. Some other commits were added to `master` since `feature` was created, and the two branches diverged.
```text
o master
|
o o feature
| |
o o
| /
o
```
In this case, there will be a label in the MR Merge box stating:
> This MR is by 3 commits behind the target branch `master`.
## Screenshots
### The branch diverged from the target (UI Proposal)

### The branch diverged from the target (alternative UI Proposal)

## How is this useful?
- In a _rebase-workflow_ (MR are preferably rebased before being merged), the reviewer wants to know if an MR is rebased on the target branch before merging it.
_With this indicator, the reviewer knows immediately if the branch is rebased, or if she needs to ask the committer to rebase its branch._
<br>
- To keep the git history readable, a team prefers to avoid merging branches that really lag a lot behind the target branch. Merging an MR that is 10 commits behind is fine, but 200 is too much.
_With this indicator, the reviewer can see on the MR page if the branch is really far behind the target – or only a few commits behind._
## Open questions
We've been using this at @captaintrain for a few months now, and found it quite useful.
I guess the open-questions are mostly: what UI would be the more adequate? Any thoughts on this, on the general usefulness and/or on the code?
See merge request !2217
1. Fix double bottom border if pagination
2. Fix broken search on forks page
4. Remove duplicate js logic
4. Remove unused show all link
5. Remove duplicate “no project” message in different views
After this merge request you can easily render shared projects template
with all necessary html/js included to make searchable list with
pagination. All you need to provide is controller that returns
projects list with seach nad pagination and render html form with
project-filter-form id and text field with filter_projects name.
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>