@@ -61,9 +61,9 @@ By default, a **Create issue** button is displayed:
![Error Details without Issue Link](img/error_details_v12_7.png)
If you create a GitLab issue from the error, the **Create issue** button will change to a **View issue** button:
If you create a GitLab issue from the error, the **Create issue** button will change to a **View issue** button and a link to the GitLab issue will surface within the error detail section:
![Error Details with Issue Link](img/error_details_with_issue_v12_7.png)
![Error Details with Issue Link](img/error_details_with_issue_v12_8.png)
If the namespace you chose to fork the project to has another project with
the same path name, you will be presented with a warning that the forking
could not be completed. Try to resolve the error before repeating the forking
process.
The fork is created. The permissions you have in the namespace are the permissions you will have in the fork.
CAUTION: **CAUTION:**
In GitLab 12.6 and later, when project owners [reduce a project's visibility](../../../public_access/public_access.md#reducing-visibility),
it **removes the relationship** between a project and all its forks.
![Path taken error](img/forking_workflow_path_taken_error.png)
## Repository mirroring
After the forking is done, you can start working on the newly created
repository. There, you will have full [Owner](../../permissions.md)
access, so you can set it up as you please.
You can use [repository mirroring](repository_mirroring.md) to keep your fork synced with the original repository. You can also use `git remote add upstream` to achieve the same result.
CAUTION: **CAUTION:**
From GitLab 12.6 onward, if the [visibility of an upstream project is reduced](../../../public_access/public_access.md#reducing-visibility)
in any way, the fork relationship with all its forks will be removed.
The main difference is that with repository mirroring your remote fork will be automatically kept up-to-date.
Without mirroring, to work locally you'll have to user `git pull` to update your local repo with the fork on GitLab. You'll have to fetch locally and push it back to the remote repo to update it.
CAUTION: **Caution:**
[Repository mirroring](repository_mirroring.md) will help to keep your fork synced with the original repository.
Before approving a merge request you'll likely to be asked to sync before getting approval, hence automating it is recommend.
With mirroring, before approving a merge request you'll likely to be asked to sync, hence automating it is recommend.
Read more about [How to keep your fork up to date with its origin](https://about.gitlab.com/blog/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/).
## Merging upstream
Once you are ready to send your code back to the main project, you need
to create a merge request. Choose your forked project's main branch as
the source and the original project's main branch as the destination and
create the [merge request](../merge_requests/index.md).
When you are ready to send your code back to the upstream project,
[create a merge request](../merge_requests/creating_merge_requests.md). For **Source branch**,
choose your forked project's branch. For **Target branch**, choose the original project's branch.