[x]
):We have a GIT server which only supports SSH for cloning, not HTTP, example:
ssh://[email protected]/source/test.git
How can I migrate a repository in Gitea ?
Or is there some other way I can do this manually ?
You have multiple choice :
There must also be others methods to do it but they should be the easy one.
@sapk : Thanks for your tips, but I already tried the Migrate form in Gitea, it does not accept SSH url's.
I have been struggling the whole day trying to find a way to clone and merge the repository, but to no avail. In theory it seems to be possible to merge from another remote repository, but I can not get it working. Copying the files and checking them in is not really an option, as this would mean loosing the tags history.
Have you try replacing ssh:// url part with git:// ?
@RickZeeland how many repos do you want to transfer over? What you could do is just clone them and push them to your Gitea server
git clone [email protected]:abc/123.git
cd 123
git remote set-url origin [email protected]:org/repo.git
git push origin master
git push --tags
The git push --tags
command will push all your tags
@sapk : Thanks, I will try that out first next week when I'm at work again.
@deanpcmad : Looks good, It's only for one big repo. I tried something like you suggested locally with drive paths but got an error when pushing, had to go through some hoops to get it working:
git config --global receive.denyCurrentBranch ignore
Git gui - Repo1 - push to Repo2
Git gui - Repo2 - visualize all branch history - r-click on revision -
reset master branch to here - Reset type: hard
@sapk : Nope, git: does not work.
@deanpcmad : It works like a charm, as long as you have a bare Gitea repository, see attached picture. Thanks !
@hetykai I have not read anywhere that this has been fixed, so I'm afraid you will have to do it from Bash with GIT commands like shown above.
Example as shown by @deanpcmad :
git clone [email protected]:abc/123.git
cd 123
git remote set-url origin [email protected]:org/repo.git
git push origin master
git push --tags
@hetykai it could also have to do with the SSH configuration which is typically found in: C:\Projects\Giteacustom\confapp.ini
How to config SSH settings
https://discuss.gogs.io/t/how-to-config-ssh-settings/34
https://docs.gitea.io/en-us/config-cheat-sheet/
DISABLE_SSH: Disables SSH feature when it鈥檚 not available.
START_SSH_SERVER: Starts built-in SSH server when enabled.
SSH_DOMAIN: Domain name of your ssh server.
SSH_PORT: SSH port displayed in clone URL, in case yours is not 22.
SSH_LISTEN_PORT: Port for the built-in SSH server. Defaults to SSH_PORT.
https://github.com/go-gitea/gitea/issues/2723
Any updates on this one? I've configured the SSH key on my user profile, but it doesn't seem to work properly with a git url. ie git://bitbucket.org:user/repo.git
I get the following error:
Migration failed: Clone: exit status 128 - fatal: unable to connect to bitbucket.org: bitbucket.org[0: 104.192.143.2]: errno=Invalid argument bitbucket.org[1: 104.192.143.3]: errno=Invalid argument bitbucket.org[2: 104.192.143.1]: errno=Invalid argument
@pgodwin as of now HTTP(S) is still the only way to mirror/migrate git repos from other systems
I'm confused, is this a conversation of the git:// URL prefix or not? If not, let me know so I can start an issue. Currently getting unable to connect and connection timed out
@BNolet No this is not a conversation of the git:// URL prefix. Don't think anything has changed and it's still not possible to migrate from SSH in Gitea, the documentation at https://docs.gitea.io/en-us/ only mentions: "Clone with SSH/HTTP/HTTPS".
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
Still an issue
Hey,
I'm seeing this as well, I think that it mostly has to do with being unable to specify a key to clone with, as if you import from an https:// link initially, and then edit the upstream url afterwards, it allows you to change it to an ssh:// link, but it gets permissions denied.
what is the current state?
Noone is currently working on this
it also confuse me
This is blocking evaluating Gitea for work. We cannot import our repo which is SSH+Keys only. The fact file:/// is also blocked seems silly to me. Basically we have no path to migrate.
@halsafar It is possible to import for disk. This is disabled by default for security reasons.
Thanks for the very quick response. How can I go about enabling that temporarily to import our repo?
@halsafar look for IMPORT_LOCAL_PATHS
documentation on this page: https://docs.gitea.io/en-us/config-cheat-sheet/ you can put the path directly, I don't think you need file://
prefix
@techknowlogick Thank you very much for the quick response! I have successfully imported our repo.
I wish for that feature too. It is not so much about migrating, but using the mirror functionality. I would like to have a mirror of a couple of remote repositories which are quite big, but low bandwidth connected on my Gitea instance. Due to the nature of password expire policies the mirror credentials often need to be updated to new passwords. This is some "maintenance" effort I would like to avoid by having SSH keys for authentication.
I wish for that feature too. It is not so much about migrating, but using the mirror functionality. I would like to have a mirror of a couple of remote repositories which are quite big, but low bandwidth connected on my Gitea instance. Due to the nature of password expire policies the mirror credentials often need to be updated to new passwords. This is some "maintenance" effort I would like to avoid by having SSH keys for authentication.
Also if more than one user is using gitea mirror repository both will see the password used for this on the administration side of the configuration.
It's extremely difficult to do this safely, securely and without it being a huge task.
I guess a blanket app.ini option of allow mirroring with SSH could work but the use of it would have to be highly discouraged and it would have to rely on default behaviour of SSH - users would have to manage the .ssh/config
But this is hardly a robust solution.
You'd really want more granular control and perhaps even a way of generating keys on Gitea which would then provide the user with a public key to put on their server.
We need a new infrastructure maybe named secrets to store all private data.
We really need this functionality
We have a lot of projects accessible via ssh only and we need this in order to fully transfer to Gitea
@Sofianio you always can clone the whole repo to a PC and push to Gitea afterwards If you need it now :)
but this feature would be very usefull 馃憤
@6543 we have a lot of projects ... that would be tedious
but i'm afraid it's the only way since this issue has been around for 3 years
you could write a script witch do the work for you - but this should be discusted outside this issue beacues it is off topic
A script would be great if there was a way to create organizations and repositories then pull/push to them
But if we have to create the orgs & repos from GUI then it's still tedious
@Sofianio as I got to know here you can set ENABLE_PUSH_CREATE_ORG
and ENABLE_PUSH_CREATE_USER
to true in your config, and then just go ahead and push, e.g. like this:
#!/usr/bin/env bash
[[ -z $ORG ]] && ORG="yourorgname"
for REPO in /path/to/repos/; do
DIR=$( basename $(pwd) )
git -C "$REPO" remote add neworigin "[email protected]:$ORG/$DIR.git"
git -C "$REPO" push neworigin master
done
Thanks :)
Hi, I am having this issue also. I discovered Gitea today while searching for a way to create a repository mirror to use as a backup. I am surprised to see it lacking the ssh pull method, as GitHub will stop supporting basic authentication on November 13, 2020 at 04:00 PM UTC. Is there any plan to allow us to use tokens to authenticate and support the ssh protocol?
I skimmed through and only see workaround suggestions, but these would not solve the mirror solution that I am looking for, which I see 3 other people mention over the past 2 years.
I think this is blocked by #12065
We'd really like to be able to do this also. We have a bunch of repos where the primaries are on various servers, and we'd like a mirror in Gitea.
I'm not sure why this is blocked by #12065 because it should work just fine if the user running Gitea can SSH to the remote servers where the repos are mirrored from (using an SSH key without password - no configuration required in Gitea at all).
Was just curious, and just had a go at hacking Gitea to support mirroring using password-less SSH. And it worked! The trouble is, I don't know much (or anything) about Go, so I mainly just commented stuff out that prevented the URL from being accepted until Gitea just went ahead and treated it as a plain Git migration. And that does work!
@zeripath It seems allowing SSH has similar security characteristics as allowing local file repos to be imported/mirrored. So it could be treated in the same way, that is, disabled by default but with a config parameter to allow it. It would help some people (including us) who now have to hack around this limitation using a local file mirror + a cron job to periodically update the local file mirror using SSH :-(
In fact, looking more closely at the changes needed to support it, it's down to a one line change: to accept the ssh:// as a valid URL, along with http://, https://, and git://.
Other than that, of course some text in the UI would need to be updated and some documentation as well.
Is there any interest in me creating a patch and push request for this?
@TheoLassonder feel free to create a pull 馃憤
Most helpful comment
@Sofianio as I got to know here you can set
ENABLE_PUSH_CREATE_ORG
andENABLE_PUSH_CREATE_USER
to true in your config, and then just go ahead and push, e.g. like this: