# Add "upstream" as a hardcoded remote name \(\#29382\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/ebb39d9231f7d957039980f9ea275b47884f8a24)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: ebb39d9231f7d957039980f9ea275b47884f8a24

Requested commit: ebb39d9231f7d957039980f9ea275b47884f8a24

Commit: ebb39d9231f7d957039980f9ea275b47884f8a24

Tree: c15b9dcf1f7953d2cb56fd99f5e4f42d4885324f

Author: Julia Ryan

Committer: GitHub

## Message

```
Add "upstream" as a hardcoded remote name (#29382)

The ideal solution here would be the ability to pick a default remote
the first time you click on a PR or commit link from a blame, and then
store that state in the repo or project and allow you to change it
somehow.

Because that's complicated, and because the vast majority of users
follow the convention of using `upstream` and `origin`, this change just
adds `upstream` as a possible remote that takes precedence for
generating links. I've sometimes seen `origin` and `fork` used for the
same purposes, which will still work fine with this change.

Here are some sources recommending the `upstream`/`origin` convention:
-
https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
-
https://github.blog/open-source/git/git-2-5-including-multiple-worktrees-and-triangular-workflows/
- https://cli.github.com/manual/gh_repo_fork

The fact that the github cli renames them to those when you `gh repo
fork` is pretty strong evidence that it's worth supporting them even if
users can set arbitrary remote names or could actually want to open a PR
link on their fork.

Resolves #13511

Release Notes:

- Git blame links now prefer the `upstream` remote over `origin` if it
exists.
```

## Parents

- [187f8516137d6c0e405225441930164c9eb0aa09](https://git.cafe/gitcafe/zed/commit/187f8516137d6c0e405225441930164c9eb0aa09?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/ebb39d9231f7d957039980f9ea275b47884f8a24?format=markdown)