Closed ahakanbaba closed 5 years ago
@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.
@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?
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.
@KostyaEsmukov Agree and I also think the same. Working on adding this.
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 ?
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.
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.
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.
But there's also an opposite scenario: one might prefer
upstream
overorigin
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.
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.
Nice discussion! Based on the discussion so far, shall we come up with the following decision?
<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
implemented at https://github.com/ruanyl/vim-gh-line/pull/28
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:
origin
useorigin
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 theupstream
does also not contain the most recent changes the author is working on. Usually the author does not have direct write access toupstream
either. So we could prioritize the remote that is NOT calledupstream
before choosing an arbitrary one by looking at the lexicographical order. I was not sure whether it is worth adding more complication to addressupstream
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 theg: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 ag:gh_remote
variable that is a dictionary.Update
Add number-letter labels to the proposed steps so that they can be referred later on.