Fix information disclosure in `Projects::BlobController#update` It was possible to discover private project names by modifying `from_merge_request`parameter in `Projects::BlobController#update`. This fixes that. - [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG.md) entry added - Tests - [x] Added for this feature/bug - [ ] All builds are passing - [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html) - [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides) - [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits) https://gitlab.com/gitlab-org/gitlab-ce/issues/22869 See merge request !2023
Right now, the following naming scheme for diff files is used: diff-1, diff-2, ... and also we have "internal" format which is file-path-HASH, where HASH is sha1 of file path. Besides, we have HASH_lineA_lineB format to link exact line number in MR diff. It makes sence to unify the way we link diff from outside, while leave "file-path-HASH" format for internal (js) usage. Changes in this commit allow to link diff just by HASH, if we don't want specify exact lines, also it changes "file-path-HASH" and "diff-NUMBER" links in code to this unified format. Inspired by #24010 and !7298
refactors update file
Currently when a user performs an update of a file through the UI and there has already been a change committed to the file the previous commits will be overwritten without a check to see if the file has been changed. This commit uses the last commit sha at the time the user starts editing the file and compares it with the current sha of the file being edited to ensure they are the same before committing the file. If the shas do not match we throw an exception preventing the commit from the commit from occurring. Fixes #5857