Allow use of remotes instead of <user>/<repo>

[jayvdb]

Many of the commands accept <user>/<repo> as an argument.

When I am in a git repository, I would like to use git remote names to select the <user>/<repo>. That is what remotes is all about.

Using remote names will help resolve problems like https://github.com/guyzmo/git-repo/issues/140 and https://github.com/guyzmo/git-repo/issues/141 , and generally provide support for use of git-repo with multiple remotes on the same host.

The typical scenario this will enable is using git repo with both the user's own fork where development occurs and where CI will usually occur, at least prior to an MR, and the upstream repo where MRs should be sent to and fetched from with the request series of commands.

In my case, these are distinct repos, and I have advanced permissions in them both, so I use both upstream and my own fork equally (and currently I'm switching the name gitlab to point to each one in order to test various features, but I'll be hacking a solution to that annoyance soon.)

[guyzmo]

Currently, the choice of using the repo slug as argument is deliberate (aka <user>/<repo>), and there are several reasons for that:

• it's to make the API simple and unified: git create and git request accept the same repo slug parameter ;
• it's not meant to be smart or automagical at this level (at least yet) ;
• it's using and managing an origin-free set of remotes (so basically, you leave git-repo managing upstream, gitlab, github, bitbucket, and gogs and you do whatever you want with any other remotes) ;

I agree adding an upstream remote when current repository is already a fork should be made simple (though, you can already do git lab add the-team/the-project upstream. If you're not using the -a/--alone switch, it'll be added to the all remote for pushes. Maybe a magical command like git target add upstream could do that job.

Whether to use a remote name instead of a repo slug is not an idea I'm against, as I don't think it should add much extra complexity to the tool. The way I see such thing would be to extend the repo_slug argument handler so:

• when an argument without a / is given,
• if the argument exists as a remote,
• the remote matches the subcommand service type specified (i.e.: gitlab.com for target being a GitlabService)
• setup the repo_slug, repo_name, user_name members accordingly.

You're welcome to join the IRC channel #git-repo on freenode to chat this (and your other issues) further! And also, thank you for all your reporting 😉

[jayvdb]

Why closed? It seems you were open to this enhancement?

[guyzmo]

hum… I think I closed it by mistake. Though I think this is only complicating the experience. The whole UX is centered around the remote git services and the project repo slugs. If you make it possible to either have a remote or a repo slug, I find it can become confusing. So I'm not strictly opposed to the idea, but I'm not for it neither.