fix: Use remote of branch rather than first remote in list (Fixes #242)

[tvsfx]

Since filing #242, I have noticed that the only issue standing in the way of my feature request there, is the selection of the first remote in case multiple remotes are available. If we do not do this, as this PR proposes, the behavior will be the (in my opinion more intuitive) behavior described in #242, namely the selection of the remote of the upstream of the current branch as the remote.

Previously, in case multiple remotes were available, and the first remote did not correspond to the current branch's remote, gitlinker failed even though the 2nd, 3rd etc. remote might still match, so the proposed behavior should cause strictly fewer failing cases, and hence be backwards compatible.

[linrongbin16]

Note:

This line

gitlinker.nvim/lua/gitlinker/git.lua

Line 370 in 542f517

if #remotes >= 1 then

is been changed last time in PR #235 , which is trying to fix issue #234 , relate comment: #234 (comment).

I actually forget why I'm doing it this way, let me consider this issue and the previous issue together, see if we have a solution to satisfy them both.

[linrongbin16]

After take a look, I think this PR makes more sense, which is also the original code logic before #235 .

The logic is: gitlinker is only sure when there's only 1 git remote configured.

If there are multiple git remotes, i.e. git remotes > 1, then gitlinker should not automatically pick the first. Because this plugin will not know which remote the user wants, so the decision goes to the user.

[linrongbin16]

I will accept this PR, after I upgrade the commons library in #245 .

[linrongbin16]

hi @tvsfx , thanks to your effort, PR is merged. Please have a try!

[tvsfx]

Thanks for looking at this so quickly!