Improve herustic to detect the remote

[ahakanbaba]

Right now the remote is assumed to be the "origin" . As here While this works for most of the use cases I am running into several internally deployed git hosting approaches, where the remote is not named "origin" but something else.

What would you think if I changed the heuristic of finding the remote to the following:

• 1 ) If there is only one remote:
  • 1a) Use the only remote. Whatever it is named
• 2 ) If there are multiple remotes
  • 2a) If there is a remote called origin use origin
  • 2b) If there is not a remote called origin use the remote name that comes first in the lexicographical order (**). Essentially chose an arbitrary one.

This will not change the plugin's behavior on the repos that currently work fine. In addition, this will make the plugin useable for repos that do not use the origin convention, but still have simple remote naming scheme. This was mentioned in #10 too.

(**) I am not super sure in this fallback option. I guess we could consider the 'upstream' convention as well. If someone is working on a forked repo, the parent is usually called upstream. Usually the upstream does also not contain the most recent changes the author is working on. Usually the author does not have direct write access to upstream either. So we could prioritize the remote that is NOT called upstream before choosing an arbitrary one by looking at the lexicographical order. I was not sure whether it is worth adding more complication to address upstream so I left it out.

We could also use a simple g:gh_remote = 'string' variable that will specify which remote to use. I am against that approach with a simple string variable. Because a vim user independently works in numerous git repositories at the same time, in parallel. The correct remote for one would not be correct for the other repo. One could make the g:gh_remote variable a dictionary to map the remote name to the current working dir, or repo name, or similar. That looks too much complication to configure but I would be open to a g:gh_remote variable that is a dictionary.

Update

Add number-letter labels to the proposed steps so that they can be referred later on.

[ahakanbaba]

@ruanyl if you are open to improving the heuristic to something similar to the description in the bullet list. I can take a stab at the implementation and testing. FYI. Please let me know.

[ruanyl]

@ahakanbaba thank you for the proposal! I'm working on something similar which allow user to choose a remote from prompt when there were multiple remotes. How do you think?

[KostyaEsmukov]

For the multiple remotes case I think that the most convenient way would be asking the user for the remote they want to use on each \gh or \gb. By asking I mean an interactive menu, something similar to what nerdtree provides for working with the file tree.

[ruanyl]

@KostyaEsmukov Agree and I also think the same. Working on adding this.

[ahakanbaba]

TL;DR: I do not think we should build something complicated in the critical path of user's interaction with vim-gh-line to address all and every possible remote configurations.

I really find this post and its accompanying talk extremely inspiring to decide what to build what not to. There, Russ Cox asks the question: Is this use case significant for us to implement a solution and maintain ?

The vim-gh-line at least should handle 1a) above, the single remote case. In the single remote case, how the plugin should behave is really obvious and simple. 2a) where we have a remote called origin is already supported and should continue to work. After those, before going lengths to handle any other use-cases, I would first wait to understand that the problem is really significant.

For example, I have 10's of different repos that I edit with vim. And I do not have a use case that extends beyond 2a). In all of my local repos, there is either a single remote, or there is a remote called 'origin' amongst many remotes. For me supporting anything else than 1a) and 2a) is not significant. Does anyone have a compelling use case that must be solved by vim-gh-line implementation ?

Alternatives:

1) In 2b) where the remotes are many, and origin is not one of them, I propose to choose an arbitrary one. But choose deterministically (first in the lexicographical order). If someone must use vim-gh-line in that configuration she could do one of the following. a) Update this ticket to describe why the use case is a significant one and argue for vim-gh-line to provide a solution. b) Duplicate the desired remote to be named something like aaa_duplicate_remote_for_vimg-gh_line. Running something like following once would work.

git config remote.aaa_duplicate_remote_for_vim_gh_line.url $(git config --get remote.actualRemote.url)

2) (I am not in favor of this) I guess if vim-gh-line must implement something, I strongly suggest to keep the common case untouched. If the repo has more then 1 remote with none of them named origin, we should ask the user to configure the preferred remote once. This can be done with: a) With a .vim-gh-line file in the root directory of the repo b) With a dictionary like variable in vimrc

g:gh_line_repo_to_remote = {
 'pattern_to_match_the_repo_name': 'preferredRemote'
}

I strongly recommend not to complicate the common use case of <leader>gh key combination and ask the user for a selection from a remote list. The user is going to select the same remote almost all the time.

Precedence.

Intellij has also a GitLink plugin that has the same functionality as vim-gh-line. There, the authors assumed that the default remote is called origin and enabled a way for the users to specify a default remote per local github repo, only one time, without adding extra steps to their key combination to launch the browser.

The snapshot is from IntelliJ Preferences Window. The settings are per local repo and sticky.

I recommend to do the same and do not add extra steps to to the key combination while launching the browser.

[KostyaEsmukov]

The user is going to select the same remote almost all the time.

This is an assumption made on behalf of all users, which I believe is rather unfair.

Consider a typical triangular workflow: there's a fork (say, origin) and an upstream. As you've noted before, upstream might be behind the origin, so there's an obvious reason why origin might be preferred over upstream.

But there's also an opposite scenario: one might prefer upstream over origin when sharing a link of a snippet from the upstream project -- the recipient might be confused to see a link to a fork rather than the original project.

So I, personally, would prefer to have an ability to choose the exact remote I need at the moment when calling \gh (which not necessarily opens a browser, but, in my case, copies the link to the clipboard).

People use different workflows and an interactive menu might be a frustration for some, so it would be nice to have it configurable. Although the other case -- a pre-defined behaviour choosing a single remote all the time, I guess will be more frustrating.

[ahakanbaba]

But there's also an opposite scenario: one might prefer upstream over origin when sharing a link of a snippet from the upstream project -- the recipient might be confused to see a link to a fork rather than the original project.

You are right. This is fair. One would not like to share a link from my personal fork to distribute.

So I, personally, would prefer to have an ability to choose the exact remote I need at the moment when calling \gh (which not necessarily opens a browser, but, in my case, copies the link to the clipboard).

@KostyaEsmukov how did you achieve that ? Did you modify the g:gh_open_command? I am interested in that. Maybe we could update the Readme to describe that use-case too.

[KostyaEsmukov]

how did you achieve that ? Did you modify the g:gh_open_command?

Yes, this is already present in the readme (last but one sample from the How to Use section):

let g:gh_open_command = 'fn() { echo "$@" | pbcopy; }; fn '

For Linux there're alternatives to the macos's pbcopy: https://superuser.com/a/288333.

[ruanyl]

Nice discussion! Based on the discussion so far, shall we come up with the following decision?

1. when there is one remote, use it directly
2. when there are multiple remotes, provides interactive interface to let user to choose. 3?. Maybe we can preserve the first user selection and use it as the default remote in the following <leader>gh. But still we can provide a new function to user which will always give user the options to choose a remote.

How do you think? @KostyaEsmukov @ahakanbaba

[ruanyl]

implemented at https://github.com/ruanyl/vim-gh-line/pull/28