Wrong selection of remote on new version of Bitbucket Linky

Rainer Standke

same problem here.

2017-04-04T14:03:35+00:00

Daniil Penkin staff

Hello @mdobrinin and @matschmann,

Thank you for using Bitbucket Linky and for reporting this issue! Sorry to hear that I broke something (again) :(

Just to clarify: does that actually happen sometimes, i.e. Linky changes its mind about the remote of one specific repo over time?

In theory, Linky starts with checking the remote of the branch you're on (remotes come generally unsorted, but the one that matches current branch tracking info is checked first). The problem, however, is that Linky only does that on project initialization, and as soon as the repo remote is resolved, it is cached. So if you open the project while you're on a branch which is tracked at private remote, Linky will prefer it instead. So this sounds like a possible reason of the behaviour you're facing (although it was like that in earlier versions as well).

I can't say that preferring origin is a good way since that name is a convention rather than a rule (same with master branch name). So I'd look into updating the URL after the current branch switches, if that makes sense. Or, given that now there's a configuration screen, let the user select the proper remote to generate links to for a given repo.

May I ask you to confirm or disprove my hypothesis? For instance, jump on a branch that points to private, then reopen the project and see where do URLs generated by Linky point to; then jump on a branch that points to origin, reopen the project and check the URLs again? Or am I completely off track?

Cheers, Daniil

2017-04-04T14:24:17+00:00

Mikhail Dobrinin reporter

I am seeing Linky opening private no matter what remote the branch is tracking on 3.3. Not sure what is really driving it to choose one over the other right now.

2017-04-04T15:14:44+00:00

Matteo

Hi,

Same here, with "origin" and "upstream". Our convention is : origin my fork, upstream the team original repo. I totally understand your point about the convention that are not rules, but why don't put a parameter in settings to allow user to choose his default remote repository ?

By this way you are very flexible for convention naming and we can re-use your plugin (because actually by pointing on the wrong remote, it is totally useless so we can't use it anymore)

BTW: Thx for this plugins, it's a cool feature, it just need some improvements to match everyone conventions.

2017-04-05T09:39:18+00:00

Daniil Penkin staff

changed status to open

Thank you for checking that out :)

Ok, I'm going to look into what might've changed recently and figure out what is the proper way of selecting a remote. I'll probably end up in some sort of configuration but will try to make the auto-guessing better as well.

2017-04-06T02:34:07+00:00

Daniil Penkin staff

changed status to resolved

Hello @mdobrinin, @matschmann and @mmelis,

I've just released Bitbucket Linky 3.4 which, along with other changes, fixes the issue you faced:

fixes non-deterministic automatic selection of the remote: now remote is selected based on the tracking information of the current branch OR when such information is not defined, picks origin remote, if it exists OR picks first remote from the list if none of the above are defined. This basically follows IntelliJ's preference, I didn't add anything new.
allows to configure a fixed remote to generate links against. If for any reason the algorithm above doesn't suit your needs, you can explicitly set a remote that Linky should always use, no matter what current branch tracking info is.