{owner} placeholder in gh api calls do not respect origin set via gh set-default #7595

Activity

1. whi-tw

   added

   bugSomething isn't workingSomething isn't working

   on Jun 19, 2023
2. cliAutomation

   added

   needs-triageneeds to be reviewedneeds to be reviewed

   on Jun 19, 2023
3. samcoe commented on Jun 20, 2023

   

   samcoe

   on Jun 20, 2023

   Last edited by samcoe

   Contributor

   More actions

   @whi-tw I don't think I would consider this a bug but rather a feature request that the api command respects repo set-default. I think it makes sense to add to the api command 👍
4. samcoe

   added

   enhancementa request to improve CLIa request to improve CLI

   help wantedContributions welcomeContributions welcome

   and removed

   bugSomething isn't workingSomething isn't working

   needs-triageneeds to be reviewedneeds to be reviewed

   on Jun 20, 2023
5. whi-tw commented on Jun 20, 2023

   

   whi-tw

   on Jun 20, 2023

   ContributorAuthor

   More actions

   @samcoe Ah, for sure - it seemed like a bug, because it was behaviour that seemed odd and doesn't seem to match up with the usage text:

   ... will get replaced with values from the repository of the current directory.

   I can't easily get around this in my use case (a sync-fork alias), as I want to make the API call against 'my' remote (origin). I think the issue is likely that my username is alphabetically sorted after StackExchange.

   aliases:
     sync-fork: |-
       !
       set -euo pipefail
       gh api "repos/{owner}/{repo}/merge-upstream" -F branch='{branch}'
       git pull

   There's no way to specify which origin is selected by BaseRepoFunc() as far as I can tell.

   Perhaps another feature could be a NamedRepoFunc() with the ability to specify a remote by name via an envar $GH_REMOTE, failing over to BaseRepoFunc() if the envar is not set.

   I have done an implementation in #7594.

   👍React with 👍1Reacted by Sam Coe
6. samcoe commented on Jun 21, 2023

   

   samcoe

   on Jun 21, 2023

   Contributor

   More actions

   @whi-tw We have discussed adding some functionality around remotes in the past but have generally dismissed them as being a bit too low level.

   Out of curiosity is there a reason why your sync-fork alias does not use the repo sync command? That command does take into account repo set-default and seems like it would fix your use case.
7. whi-tw commented on Jun 21, 2023

   

   whi-tw

   on Jun 21, 2023

   ContributorAuthor

   More actions

   That makes sense.

   Yeah, I did see repo sync, just when I was playing with it, it didn't seem to actually do what I wanted. Well, I couldn't be sure that it would actually doing what I wanted from the usage text.

   I presume that if I set the default origin to my fork, it'll sync it against the fork's origin?

   I think maybe it's a language thing - is the source of my fork the 'parent'?

   I guess when writing the alias, I was hoping to avoid trying to understand how repo sync actually worked, and just to use the API endpoint that I know will do what I want. Unfortunately that didn't turn out to be such a quick process as I've ended up down this placeholder yak shave!
8. samcoe commented on Jun 23, 2023

   

   samcoe

   on Jun 23, 2023

   Contributor

   More actions

   @whi-tw repo sync does call the /merge-upstream API endpoint underneath the covers. You are correct, the source of a fork repo is its parent repo. Unfortunately now that I think about the command behavior a bit more, it does require the user to specify any remote repo explicitly. It won't assume a default repo according to what was selected with repo set-default, as the default behavior is to sync the local repo from its remote parent.
9. samcoe

   closed this as completedin #7594on Jul 6, 2023