ebb39d9231
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. |
||
|---|---|---|
| .. | ||
| src | ||
| test_data | ||
| Cargo.toml | ||
| LICENSE-GPL | ||