guyzmo / git-repo

Git-Repo: CLI utility to manage git services from your workspace
https://webchat.freenode.net/?channels=#git-repo
Other
842 stars 86 forks source link

request fetch <user>/<repo> must be same as the default gitlab remote #140

Closed jayvdb closed 7 years ago

jayvdb commented 7 years ago

git repo says it supports user>/<repo> for the request fetch command , like the request list command, but it seems to always look for a gitlab remote, and the <request> id must be on the gitlab remote, which means the use of <user>/<repo> on the command line is superfluous.

git-repo [--path=<path>] [-v...] <target> request <user>/<repo> (list|ls)
git-repo [--path=<path>] [-v...] <target> request <user>/<repo> fetch <request> [-f]
$ git lab request coala/package_manager list
List of open requests to merge:
 id title                                                           URL
 31 MavenRequirement: Prevent test fails                            https://gitlab.com/coala/dependency_management/merge_requests/31
 30 DistributionRequirementTest: Fix assertRaisesRegex              https://gitlab.com/coala/dependency_management/merge_requests/30

$ git lab request coala/package_manager fetch 31
Fatal error: Could not find remote gitlab

I have a remote for coala/package_manager , but it isnt called gitlab. (it is my origin)

If I do name that remote gitlab, then I dont need to specify coala/package_manager on the command line, as it is the default anyway, so I can simply use request fetch 31.

Rather than removing this unusable feature, I would prefer that it works, at least when there is already a remote for the requested <user>/<repo>, but it should also be relatively easy to fetch the MR without a remote for the requested <user>/<repo>.

guyzmo commented 7 years ago

I'm actually having a real tough time to correctly design the request create and request fetch commands so they work as expected across all service, with the right amount of automagic needed. I still am having a hard time trying to decide and figure the RIGHT, NATURAL and EXPECTED way for the command to work (mostly with request create).

Though, that being said, the behaviour you're describing sounds like a bug to me, and should be fixed. I think doing it is not obvious, as you cannot fetch PR branches from repositories that are not remotes. So there are different cases to work with:

  1. the repo slug is already a remote locally, and you want to fetch from it
  2. it's not, and you need to add a remote

the easy way would be to tell the user to GTFO (but in a nice way, giving a way to make it work — adding a remote for the repo slug) for ②, and just do it for ①.

jayvdb commented 7 years ago

as you cannot fetch PR branches from repositories that are not remotes

Im not sure about the history, but this is possible in recent versions of git, using the following

git fetch git@gitlab.com:user/repo.git branch-name-to-fetch
git checkout -b random_branch FETCH_HEAD

I suspect it has worked for a long time, as gitlab's own MR command line instructions offer this as the way to fetch an MR. If it doesnt work on older git, nobody has noticed ...

guyzmo commented 7 years ago

ok, I'll give that a try, I'm a bit afraid of the side effects of fetching a PR for project Foo/Bar into repo Non/related, and also if doing so makes it possible to keep updating from the remote branch without having a remote.