<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=585218) </details> <!--IssueSummary end--> The following discussion from !212285 should be addressed: - [ ] @vyaklushin started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/212285#note_2981214818): (+2 comments) > **question (blocking)** For scenario 2, after a maintainer edits a file in the merge request, the maintainer gets redirected to the blob view page in the fork. The user has to manually go back to the merge request to see the changes. > > Should we redirect the user back to the merge request after editing file to avoid backtracking? :thinking: ## Details **Scenario 2: Maintainer editing in a contributor's fork** * **Who**: A maintainer/developer of the upstream project (e.g., `gitlab-org/gitlab`) * **What**: Edits a file via the web editor * **Where**: On a branch that lives in someone else's fork (e.g., `contributor/gitlab`) * **Context**: Through an MR that has "allow commits from upstream members" enabled The system recognizes they're editing in someone else's fork, routes API calls to the fork project, commits changes to the fork's branch, and redirects to the file's blob page in the fork project.