Repository navigation
Add documentation on using the 'base' remote #1864
Description
Activity
If I'm not mistaken, you can use the
-Ror--repoflag to specify the repo you wish to see issues from.Yes, but you can't alter the 'base' aka 'default' remote that you originally chose, perhaps in error, without messing with the local git config settings. It's tedious to have to use
-R/--repowhen simply documenting how to fix the 'base' setting would circumvent that.Reacted by Shubhankar Kanchan GuptaNow, when I did this the first time I selected the wrong repo and started trying to figure out how to correct this mistake. There is no documentation that I could find that described what to do. I eventually figured out the following:
Thank you for sharing your workaround, and sorry for the lack of transparency around this! We briefly considered the possibility that someone might choose wrong, but we didn't have time to implement a solution for that for v1.0. We will definitely aim to improve this in a next release 🙇
Reacted by John Murray and Colton SaskaI found out that this lack of prompts is going to be an issue in every command that faces the dilemma of remotes. Should
ghprompt everytime? Or should there be an option that removes the "memory" part ?@ShubhankarKG Prompting for base repo every time would quickly become exhausting, I think. Perhaps we should give users more option to control the resolution step or clear out the cache.
I'd agree that being continually prompted for a base repo would be a disincentive to use
gh. I think a minimal resolution would need the:- Ability to query the current repo's 'base' remote setting,
- Ability to clear the current repo's 'base' remote setting.
Keep it as simple as possible since I think that
ghis about simplicity and convenience.Reacted by Mislav Marohnić and James MighionPerhaps
gh config get remote gh config set remote url?
Then, when the prompt configures a default, we can say
Your remote is configured to url. To change it, use gh config set url.Or something along those lines.
I'm minded not to pre-empt a specific solution but to let the
ghdevelopers come to a suitable use case/syntax that fits in with theirghcli command design and with any other enhancement requests they need to take into account to solve the issue I initially raised and hope these comments help them understand the issues.Just a couple of observations for the record though:
- The
getmatches my previous point 1, so I can query the value the base remote setting. - The use of the word
remotedoesn't capture the sense of the what thegetis meant to do. What is being cached is an identification of the single upstream remote repo that you've forked ongithub, cloned locally and which contains all the issues and pull requests that you're interested in. Your repo can contain many remotes. If it was up to me I'd maybe use something likebase_remoteto clarify its use. - The
setfor a remoteurldoesn't seem to address the second point I made of being able to clear out the cache. I can't see how I'd be able to get the config setting back to theunsetstate using this syntax without overloading the meaning ofurlvalue.
Just my 2-pence worth.
- The
Totally agreed on the remote part, just that I couldn't come up with a better name at the time of writing.
On the
setpart, if we have theresetfunctionality, we will have to prompt again the next time this pops up. The benefit withsetwould be that we can change the config to something, rather than leave it empty.I don't have any problem with the prompt. It keeps things simple; I do it once ( as long I get the selection right :-) ) and I don't have to worry about getting a URI wrong by mis-typing or cut/paste since it has to be one of the remotes from
git remote -v. If you want to discuss the 'tty prompt' in more general terms feel free to open an issue about it specifically.Reacted by Shubhankar Kanchan GuptaI found my way here because of the article below. I picked the wrong repo when using
gh repo sync; Then I couldn't figure out how to undo or switch the setting. I looked around the CLI documentation forgh repoand couldn't find anything.source: https://dev.to/utsavladani/how-to-change-base-repo-in-github-cli-5fhp
Thanks everyone for your feedback and sorry for the nuisance that was having to edit
.git/configmanually. In the most recent release, there is now thegh repo set-default --unsetcommand for this. The documentation is atgh repo set-default --help. Please leave further feedback here #6777
Describe the feature or problem you’d like to solve
I have a forked repo with two remotes 'origin' and 'upstream' using the standard nomenclature as you can see here:
If I want to see the issues I do the following and select the upstream (base) repo. All well and good and 'upstream' is now selected as the 'base' repo.
Now, when I did this the first time I selected the wrong repo and started trying to figure out how to correct this mistake. There is no documentation that I could find that described what to do. I eventually figured out the following:
The base repo is set as the key value pair in the local git config and only by unsetting this key value pair could I reset the github cli 'memory' of the incorrect setting.
Proposed solution
Simply document, maybe in a FAQ, how to reset the 'base' repo config setting in github cli and avoid users having to do what I did and figure out how to fix it themselves.
Additional context
None