Closed jayvdb closed 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:
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 ①.
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 ...
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.
git repo says it supports
user>/<repo>
for therequest fetch
command , like therequest list
command, but it seems to always look for agitlab
remote, and the<request>
id must be on thegitlab
remote, which means the use of<user>/<repo>
on the command line is superfluous.I have a remote for
coala/package_manager
, but it isnt calledgitlab
. (it is myorigin
)If I do name that remote
gitlab
, then I dont need to specifycoala/package_manager
on the command line, as it is the default anyway, so I can simply userequest 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>
.