Cloning repos with slashes in their names

[LordMike]

Hey,

I'm trying to clone a repo using this guide. I've set up my remotes without any user or group names in them (ie. https://user@host/), expecting to be able to clone a/b to effectively get https://user@host/a/b.git -- but this doesn't work.

$ mu clone A/B

 . : git config --get-regexp mu-repo.remote-base-url
Unable to clone because the repository name for cloning with mu was not detected.

If I clone something without slashes, it shows the paths it tries (which would be correct, if I had a project with that name :P).

Could slashes in repo names be allowed? :)

[fabioz]

I agree it's something that could be supported... would you like to provide a patch?

The related code is straightforward: https://github.com/fabioz/mu-repo/blob/master/mu_repo/action_clone.py

Maybe just removing the / check in https://github.com/fabioz/mu-repo/blob/master/mu_repo/action_clone.py#L66 could fix it.

[LordMike]

I wouldn't know how to test it :P

But it certainly seems like that slash-filter would be the culprit.

[LordMike]

I've also found that doing a mu clone A sets up a remote which is https://host/user/A (using a base url with user in it). On my Gitlab instance, this is invalid, but Gitlab silently fixes it by redirecting to https://host/user/A.git.

The issue though, apart from the unecessary redirect, is that all the common commands, like mu st, will no longer combine repos into one line, since every repo now has an "error" -- the redirect message.

[LordMike]

$ mu clone ProjectA ProjectB

<... Tries other bases I've configured ...>

 . : git clone https://scm.mbwarez.dk/test-group/ProjectA
Cloning into 'ProjectA'...
Username for 'https://scm.mbwarez.dk': mike
Password for 'https://mike@scm.mbwarez.dk':
warning: redirecting to https://scm.mbwarez.dk/test-group/ProjectA.git/
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.

Notice the redirect in the above.

Then when I do mu up (after a mu register --all)

$ mu up
Will handle origin master for: ProjectA, ProjectB

 ProjectA : git fetch origin master:refs/remotes/origin/master
    warning: redirecting to https://scm.mbwarez.dk/test-group/ProjectA.git/

 ProjectB : git fetch origin master:refs/remotes/origin/master
    warning: redirecting to https://scm.mbwarez.dk/test-group/ProjectB.git/

If I instead do a clone using mu clone ProjectA.git, I get no redirect:

$ mu clone ProjectA.git ProjectB.git
 . : git clone https://scm.mbwarez.dk/test-group/ProjectA.git
Cloning into 'ProjectA'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.

$ mu up
Will handle origin master for: ProjectA, ProjectB

Repositories fetched with no changes: ProjectA, ProjectB