always set `upstream` as default remote

[scarf005]

The problem

due to origin being default remote, opening issue/PR on gitlens constantly opens the nonexistent link on fork.

this can be addressed by manually setting default remote to upstream in REMOTES pane, but it would be more ergonomic to do it automatically since forks have upstream remote.

Steps to reproduce

Prerequisites

• original repo and its issue: An issue in the upstream repo bbbchiv/2#1
• the fork, no issues: https://github.com/sergeibbb/2
• No default remote
  
• rich integration is OFF
• a commit linked to the original issue: sergeibbb/2@59f4cf9

Actual result

• autolink in a blame pop-up goes to origin:
  • 
• if a commit is linked to the PR it links to origin as well.

Explanation

It's in sorting.ts where origin goes earlier than upstream

export function sortRemotes<T extends GitRemote>(remotes: T[]): T[] {
	return remotes.sort(
		(a, b) =>
			(a.default ? -1 : 1) - (b.default ? -1 : 1) ||
			(a.name === 'origin' ? -1 : 1) - (b.name === 'origin' ? -1 : 1) ||
			(a.name === 'upstream' ? -1 : 1) - (b.name === 'upstream' ? -1 : 1) ||
			sortCompare(a.name, b.name),
	);
}

Then it goes to hovers.ts where the first remote is taken:

remotes = remotesResult.value;
[remote] = remotes;

The proposal

Let user configure a default remote name that would go before origin. Or even let user configure a preferred sequence so it would work like: const preferredRemoteNames = getConfigured() ?? ['origin', 'upstream']

[sergeibbb]

Hi @scarf005

Would you mind to describe steps when you got origin to be automatically selected as default:

• Does it happen when you open a new repo with several remotes for the first time?
• Does it happen when you have a repository with several remotes where none is selected as default? In this case is the origin gets selected immediately or after some actions?

[xtqqczze]

Would you mind to describe steps when you got origin to be automatically selected as default:

% gh repo clone xtqqczze/dotnet-sign
Cloning into 'dotnet-sign'...
...
! Repository dotnet/sign set as the default repository. To learn more about the default repository, run: gh repo set-default --help
% code dotnet-sign

Opening an issue or pull request in GitLens always redirects to a non-existent link on the fork.

[xtqqczze]

• Does it happen when you have a repository with several remotes where none is selected as default? In this case is the origin gets selected immediately or after some actions?

None of the remotes appear to be set as the default, but GitLens still uses the origin remote when opening an issue or pull request.

[sergeibbb]

@axosoft-ramint , @eamodio

I've reproduced.

Prerequisites

• original repo and its issue: An issue in the upstream repo bbbchiv/2#1
• the fork, no issues: https://github.com/sergeibbb/2
• No default remote
  
• rich integration is OFF
• a commit linked to the original issue: sergeibbb/2@59f4cf9

Actual result

• autolink in a blame pop-up goes to origin:
  • 
• if a commit is linked to the PR it links to origin as well.

Explanation
It's in sorting.ts where origin goes earlier than upstream

export function sortRemotes<T extends GitRemote>(remotes: T[]): T[] {
	return remotes.sort(
		(a, b) =>
			(a.default ? -1 : 1) - (b.default ? -1 : 1) ||
			(a.name === 'origin' ? -1 : 1) - (b.name === 'origin' ? -1 : 1) ||
			(a.name === 'upstream' ? -1 : 1) - (b.name === 'upstream' ? -1 : 1) ||
			sortCompare(a.name, b.name),
	);
}

Then it goes to hovers.ts where the first remote is taken:

remotes = remotesResult.value;
[remote] = remotes;

The proposal

Let user configure a default remote name that would go before origin. Something like:

function sortRemotes<T extends GitRemote>(remotes: T[]): T[] {
	return remotes.sort(
		(a, b) =>
			(a.default ? -1 : 1) - (b.default ? -1 : 1) ||
                        (a.name === CONFIGURED_DEFAULT_REMOTE ? -1 : 1) - (b.name === CONFIGURED_DEFAULT_REMOTE ? -1 : 1) ||
			(a.name === 'origin' ? -1 : 1) - (b.name === 'origin' ? -1 : 1) ||
			(a.name === 'upstream' ? -1 : 1) - (b.name === 'upstream' ? -1 : 1) ||
			sortCompare(a.name, b.name),
	);
}

Of course, we could go further and let user configure a preferred sequence so it would work like:

const preferredRemoteNames = getConfigured() ?? ['origin', 'upstream']

function sortRemotes<T extends GitRemote>(remotes: T[]): T[] {
	return remotes.sort(
		(a, b) =>
			(a.default ? -1 : 1) - (b.default ? -1 : 1) ||
                        ... use preferredRemoteNames ... ||
			sortCompare(a.name, b.name),
	);
}