Repository navigation
Confirm base repo on first resolve #924
Description
Activity
cc @ampinsk and @billygriffin -- curious what y'alls takes on this are.
(chatted with billy synchronously and he's 👍 )
Should we tell them how to unset it when we set it?
@vilmibm and I talked about letting them know how to change the setting in the immediate output, but likely not after that except in documentation. I think the most likely scenario for someone wanting to change it is immediately realizing they accidentally chose the wrong repo, and less likely that after using it one way for a certain amount of time, they'll want to change it later.
How should a user unset this? via git config or a command we provide?
Leveraging git config seems fine here. I think it's relatively unlikely this will be changed back and forth regularly.
Is there value in the other option as shown above?
😬 I have no idea. Where are the options provided coming from, and what are potential gaps where someone might choose something that wouldn't be listed?
How can the wording be improved? I'm not thrilled with my first pass.
Maybe instead of "query" we can try to be a bit more explicit about what the implications are? Something like,
Which remote repository would you like gh to use for creating and displaying objects?I don't love my wording either, but just thinking that something a bit more descriptive would be helpful in making the choice a bit simpler to understand.I fully support the initiative of asking the user about the "base" repo and remembering that choice after first run in the repo. I think the trickiest obstacle would be finding the correct wording. Here is my braindump for now:
-
From the prompt itself it should be clear that that is a one-time question and that the answer will be persisted.
-
The user should be able to understand what is the scope of their choice, i.e. which operations will it affect. Is it only for looking up issues/PRs?
-
We should never prompt in non-interactive contexts (scripts, CI). In those cases, what should the default be? For simplicity sake, I vote that we simply query the repo from the first git remote we find (with a preference for
upstream,github, andoriginif any of those exist). -
We should never prompt for "simple" cases, i.e. when you have a single git remote pointing to a repository that is not a fork of anything.
As an example of prompting causing fatigue, I remember getting really tired of
travis(the official CLI for Travis CI) prompting for confirmation after its own repository resultion logic. It only did that once per repository, but I had many repos configured with Travis and I did not understand why it has to prompt every time, especially in cases where there wasn't any abiguity. Let's avoid doing that. -
If the user chooses "wrong", how will we enable them to recover from it?
-
Describe the feature or problem you’d like to solve
"Base" repository resolution (in other words, the specific
owner/reporemote on GitHub that should be consulted byghfor pull requests, issues, etc) is tricky and any attempt to it in an automated, clever way will inevitably fail for a nontrivial number of users. It's also a very slow process which we currently perform on almost every command.We some open issues around this now: #317 #458 and have closed others as dupes.
This issue covers explicitly confirming which base repository the user wants to associate with a given local repository be default.
Proposed solution
This issue proposes a flow of:
If we see a
--repoflag or detect that we're not running interactively, we will not perform this prompt.Additional context
Mislav and I have discussed this issue at length a few times and have not come up with a better solution than prompt-on-first-use for base repository setting.
Open questions
git configor a command we provide?otheroption as shown above?