remote: support remotes referred by URL only

[bmeneg]

When using git-push the user can set the upstream of a branch to a
remote that is not present in the current repository by referring to its
URL. In these cases, git checks for the validity of the URL itself
instead of checking if a remote with that name exists locally.

I.e.:

$ git push --set-upstream <URL>

This case affects lab mostly when we use the remote URL to lookup for it
in GitLab: lab checks for the branch's remote name.
branch.<branch>.remote, then it gets the remote URL itself; however,
in this situation, the branch.<branch>.remote will be the URL already
and any check for that remote in the local repository fails.

The biggest problem is the amount of different URL formats supported by
Git [1], which is bigger than the ones supported by the usual
url.Parse() (net/url Go module). Because of that, I brought the git-urls
module to help.

This new module threat anything that isn't an external URL as a possible
file URL, meaning that default remote names are also accepted, with that
we can pass all our remote names (URL or not) to its Parse() function
and just use the "path" component, which is pretty close to what we need
for the GitLab lookup.

[1] https://git-scm.com/docs/git-push#URLS

Signed-off-by: Bruno Meneguele bmeneg@redhat.com

Related: #381

[bmeneg]

I'll move this MR to draft until I get the tests fixed.

[codecov]

Codecov Report

Merging #793 (bbd51a7) into master (3609244) will decrease coverage by 0.35%.
The diff coverage is 29.66%.

@@            Coverage Diff             @@
##           master     #793      +/-   ##
==========================================
- Coverage   55.07%   54.72%   -0.36%     
==========================================
  Files          77       77              
  Lines        5641     5681      +40     
==========================================
+ Hits         3107     3109       +2     
- Misses       2255     2289      +34     
- Partials      279      283       +4     

Impacted Files	Coverage Δ
cmd/root.go	57.79% <ø> (ø)
internal/gitlab/gitlab.go	7.79% <17.44%> (+0.41%)	⬆️
cmd/ci_run.go	63.63% <33.33%> (-1.99%)	⬇️
cmd/fork.go	63.15% <50.00%> (ø)
internal/git/git.go	55.02% <50.00%> (-1.79%)	⬇️
cmd/util.go	74.06% <73.33%> (-0.87%)	⬇️
cmd/mr_create.go	75.11% <100.00%> (+0.11%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f68cb49...bbd51a7. Read the comment docs.

[prarit]

@bmeneg , it's always easier for me to see a real world example. Can you show me how this would actually work within a git repo?

[bmeneg]

@prarit yes sure.

One practical usage of it is on CI environments where remote names are not really required/used.

But something simpler: the user can setup a repository and for whatever reason push things so some repository using the remote URL instead of the same itself. For instance:

$ git clone https://github.com/bmeneg/lab
$ git checkout fix-awesome-feature
<.. do some work ..>
$ git push https://github.com/zaquestion/lab

works just fine.

At the same time, the user can set that remote URL as a real tracking remote:

$ git push -u https://github.com/zaquestion/lab test_branch

Causing the branch.test_branch.remote to be an URL instead of an usual name, as we are more used to do, thus, every subsequent git push would push to that URL directly, meaning no remote name lookup nor anything, just straight push to a branch in that repo URL.

I personally don't use remote URLs directly, but Git does support it and mention it in the first lines of the git-push help:

<repository>

    The "remote" repository that is destination of a push operation. This parameter can be either a URL
    (see the section [GIT URLS](https://git-scm.com/docs/git-push#URLS) below) or the name of a remote 
    (see the section [REMOTES](https://git-scm.com/docs/git-push#REMOTES) below).

NOTE: I flxed the test code, I'm going to move the PR to ready state.

[bmeneg]

Ah, one thing that might help a bit to understand is: we need to distinguish between a remote name vs url because today we use it to retrieve GitLab's project:

remote_name = branch.<branch_name>.remote
remote_url = remote.<remote_name>.url
gitlab.GetProject(remote_url)

however, in case we don't have a real remote name, but a remote url instead, we have to skip the second step from above, ending up with the following flow:

remote_url = branch.<branch_name>.remote
gitlab.GetProject(remote_url)

[bmeneg]

@prarit did my comments help you understand the situation this PR is trying to solve?