Due to my old installation of Gitlab being too difficult to upgrade (Thread on TKL support forums: http://www.turnkeylinux.org/forum/support/20120913/upgrading-gitlab ), I have downloaded the current TKL Gitlab distro, and followed Gitlabs standard upgrade path so that I now have a fully upgraded Gitlab 6.1 installation running with TKLBAM and all that good stuff. So far so good.
But, it turns out that our old version of gitlab does not give HTTP urls to repos, so that means that I can't use the "Import existing repository" function in Gitlab 6.1
I know that i can simply copy the old Git repositories from the old VM to the new one, but how can I make these repositories visible in Gitlab on the new VM?
I recently migrated from gitolite to gitlab and the official rake task gitlab:import:repos worked for me. I am using gitlab 6.1.0 (82f3446). Here is what I did:
rsync bare repos from gitolite to repositories/{group}/. Make sure to replace {repository} with the name of the gitolite repo, and change the hostname of your gitlab server.
rsync -rth --progress repositories/{repository}.git \
git#gitlab-server:/home/git/repositories/{group}/
Here, {group} is the name of the user group you want the repository to be added to. If you don't have any specific group, choose root as the group name.
Fix permissions – only necessary when the rsync user is not git:
sudo chown -R git:git repositories/{group}/
cd ~/gitlab
Run the rake task to import all new repositories:
bundle exec rake gitlab:import:repos RAILS_ENV=production
Now if you login as Administrator you will find the new project added.
For more information, refer to the "Import bare repositories into GitLab project instance" under http://{your-gitlab-server}/help/raketasks.
In your case, you can login to your old TKL system and rsync all bare repos to the new instance, followed by an import.
One option would be to:
Clone the old repo from gitlab onto a dev machine.
Create a blank repo on the new gitlab.
Add the new repo as a remote on the dev machine.
Push everything back to the new repo.
Remove the old repo from remote repos list.
To create a remote called newRepo, do: git remote add newRepo gitlab.localhost.com:User/newRepo.git (replace the url on the end with the one for your repo)
I did it practically the following way after reading ChrisA answer, which gave me a little headache about how to do it practically. The example copies a repo from github to gitlab, to make source and destination a little bit clearer.
Clone the old repo from github onto a dev machine (which creates a bare repo):
$ git clone --mirror git#github.com:me/myrepo.git
Create a blank repo on the new gitlab.
Add the new repo as a remote on the dev machine.
$ cd myrepo.git
$ git remote add newRepo git#gitlab.com:me/myrepo.git
Push everything back to the new repo.
$ git push --mirror newRepo
That's it.
This way it copied all branches and tags to the new destination.
You can now remove the cloned bare repo from your dev machine.
If your Gitlab is >= 8.9, then you can use export/import to migrate repos.
Since GitLab 13.8 (January 2021), you now have:
Migrate Groups directly between instances
A faster and easier way to migrate your GitLab Groups is on the way.
Group Migration is a new feature that lets you copy a GitLab Group from one instance to another directly, without having to export and import any files.
In this release, we migrate only the Group object with basic fields.
We plan to follow up with more and more fields and related objects until all relevant data in a Group is migrated in this easy-to-use fashion.
See Documentation and Epic.
Related
I have a VPS running a Node.js / React app.
I want to update the files in the vps each time I push data to the git(hub).
I found out, using this answer, that I can add some hooks in git, executing commands on "post-receive".
What I didn't quite understand :
Why did he init another git ? Couldn't he have done this in the .git directory and create the hooks/post-receive file?
Why git checkout -f ? If the goal is to update local files, so nodemon / create-react-app restarts the server / app, why not execute a git pull instead ?
Is there a better way of doing this ?
In the recommended answer there, nobody is using GitHub and there is no other Git repository yet. So the answer to your question:
Couldn't he have done this in the .git directory and create the hooks/post-receive file?
is: No, there was no .git directory in the first place. The target machine had nothing at all, no Git repository, no working tree, etc. The git init --bare created the Git repository (the ".git directory").
The git checkout -f is a poor-man's / low-quality implementation of push to deploy. A receiving repository is normally "bare", and this one is no exception.
why not execute a git pull instead ?
That would require creating a third Git repository. That would have been an option.
"Better" is in the eye of the beholder. There are many ways of doing this, each with its own pluses and minuses. See also Deploy a project using Git push, which notes that since Git 2.3, receive.denyCurrentBranch = updateInstead is available; it was not available prior to 2015 (and in 2015, many people had older versions of Git installed).
Note further that if you're using GitHub as a hosting system, this changes a number of variables. The questions and answers you and I have linked here are aimed at those not using GitHub.
Just installed a fresh new 6.8 Gitlab on a brand new high performance server.
Before considering to forget my repositories history (comments, issues, etc...), do one know of a way to export a repository data from a Gitlab server to another Gitlab Server ?
I just failed to found anything on the documentation for exporting/migrating the whole project data (not just the git repository and its wiki).
For GitLab versions >= 8.9 (released in June 2016) you can use the built-in export and import project feature.
Please not that for the existing installations of GitLab, this option has to be enabled in the application settings (URL: /admin/application_settings) under 'Import sources'. You have to be a GitLab admin user to enable and use the import functionality.
Here is the feature complete documentation: https://gitlab.com/help/user/project/settings/import_export.md
I have actually done this recently, we were upgrading our instance of gitlab and needed to save and import repositories to the new installation.
First, create a bundle of the checked-out repository. For example, say you checked out a repository we will call myrepository
To check out the repository use git clone (let's assume your repository is under the root account and the ipaddress is 192.168.1.1)
git clone http://192.168.1.1/root/myrepository.git (or match your environment)
Now this step is somewhat important; you need to change into the working directory that has the .git folder of your checked out repository.
cd myrepository
Next, you create a bundle file:
git bundle create myrepository.bundle --all
Import the bundle file into the new instance of gitlab.
Create a new 'myrepository' on the gitlab gui interface
clone the empty repository; let's say this new gitlab has the ipaddress 192.168.1.2:
git clone http:\\192.168.1.2\root\myrepository.git (or match your environment)
You will get warnings that you cloned an empty repository. This is normal.
Change into the working directory of your checked out repository and do a git pull:
cd myrepository
git pull file/path/to/myrepository.bundle
this will pull the repository into your clone. Next you can do a git add, git commit and git push
This should work assuming you have the gitlab server settings set up correctly; you may have issues such as needing to add a client_max_body_size parameter in your nginx.conf file and also a 'git config --global http.postBuffer' to push large files.
Another way to do this is to make patch files of each commit and then deploy them:
This involves doing a 'git format-patch -C 0badil..68elid -o patch_directory_path' and reference the range of all your commits and have them pushed to an output directory; this should give you one patch file per commit. Next would involve git cloning the new empty repository, changing into the working directory of the clone and applying the patches to the new repository using 'git am patch_directory_path'
For GitLab versions < 8.9, without built-in export/import feature, I recommend a great tool from Marcus Chmelar, gitlab-migrator. I used it successfully many times with older GitLab versions so you should too. Just be aware of its limitations.
For the repos themselves, you can use git bundle: that will generate one file, that it is easy to copy around.
(as I described in "Backup a Local Git Repository")
But another way is simply to git clone --mirror your repos from the first server on a local workstation, and git push --mirror to the new server.
This is what GitHub details in its help page "Duplicating a repository".
In both cases, you need first to declare those repos on the new GitLab server, in order for them to be initialized, and ready to receive commits.
But for the rest... not easily. There is a feature request pending:
(Update August 2016, 2 years later: GitLab 8.9 has that feature implemented)
(for GitLab version older than 8.9, see and upvote Greg Dubicki's answer)
I agree that issues are the main thing to make exportable first.
They are stored in the database. Storing them in git is not an option. Maybe export them as a formatted file (SQL, YAML or something else).
This blog post illustrates the export of a mysql database.
Use mysqldump to create dump of old database, then create a new database on the new server and import this.
On old:
mysqldump gitlab | gzip > gitlab.sql.gz
On new:
gunzip < gitlab.sql.gz | mysql gitlab
Run the db migrate command to make sure the schema is updated to the latest version.
sudo -u gitlab -H bundle exec rake db:migrate RAILS_ENV=production
First off, forgive me if this is a duplicate question. I don't know anything but the basic terminology, and it's difficult to find an answer just using laymen's terms.
I made a project, and I made a repository on Github. I've been able to work with that and upload stuff to it for some time, on Windows. The Github Windows application is nice, but I wish there was a GUI for the Linux git.
I want to be able to download the source for this project, and be able to edit it on my Linux machine, and be able to do git commit -m 'durrhurr' and have it upload it to the master repository.
Forgive me if you've already done most of this:
The first step is to set up your ssh keys if you are trying to go through ssh, if you are going through https you can skip this step. Detailed instructions are provided at https://help.github.com/articles/generating-ssh-keys
The next step is to make a local clone of the repository. Using the command line it will be git clone <url> The url you should be able to find on your github page.
After that you should be able to commit and push over the command line using git commit -am "commit message" and git push
You can use SmartGit for a GUI for git on Linux: http://www.syntevo.com/smartgit/index.html
But learning git first on the command line is generally a good idea:
Below are some basic examples assuming you are only working from the master branch:
Example for starting a local repo based on what you have from github:
git clone https://github.com/sampson-chen/sack.git
To see the status of the repo, do:
git status
Example for syncing your local repo to more recent changes on github:
git pull
Example for adding new or modified files to a "stage" for commit
git add /path/file1 /path/file2
Think of the stage as the files that you explicitly tell git to keep track of for revision control. git will see the all the files in the repo (and changes to tracked files), but it will only do work on the files that you add to a stage to be committed.
Example for committing the files in your "stage"
git commit
Example for pushing your local repo (whatever you have committed to your local repo) to github
git push
What you need to do is clone your git repository. From terminal cd to the directory you want the project in and do
git clone https://github.com/[username]/[repository].git
Remember not to use sudo as you will mess up the remote permissions.
You then need to commit any changes locally, i.e your git commit -m and then you can do.
git push
This will update the remote repository.
Lastly if you need to update your local project cd to the required directory and then:
git pull
To start working on the project in linux, clone the repo to linux machine. Add the ssh public key to github. Add your username and email to git-config.
For GUI you can use gitg.
PS : Get used to git cli, It is worth to spend time on it.
I am fairly new to Git. I have worked locally, but today i need to setup a remote machine with the git. I have no idea how.
Basically my setup is like this.
I have a windows machine which has a vmware player installed, which is used to connect to the dev ubuntu linux machine where out Git repo is situated. I putty to the dev machine and do all the operation related to git with username common to all the developers username : dev
Now there is a new rollup that is created in the dev git repo which is required to be deployed on our ubuntu linux test server. I have my account in test server. username:ash.
What are the steps that should be followed to setup this. I have some time back had a discussion with one of my colleague who had shared about using SSH key. As he is the only contact person who is not available, I have no info how to proceed. I have created the SSH key.
login to the machine as "ash".
ash#gitserver:~$
create a new directory that will contain the git-repository
ash#gitserver:~$ mkdir rollout.git
change into the directory
ash#gitserver:~$ cd rollout.git
initialize the git repository
ash#gitserver:~/rollout.git$ git init --bare
go back to your dev machine and clone the newly created repository or add it to the "remote"s of an existing git repo. use "ssh://ash#gitserver/~/rollout.git" as the remote-url.
[update for cloning]: make sure that there is not already a "rollout" directory in the directory where you want to clone to. for simplicity, create an empty directory "foo/" and try to clone into that directory. you can then move the cloned repository to wherever you want to.
push changes to the new repository.......done!
the use of ssh-keys will make authentication simpler and/or more secure but is in no ways necessary (or related) to setting up the git repository.
I don't understand how do I create a post-receive hook for a specific repository in gitolite (non-root install)
My bare repository contains a website that should copy the working directory to the docRoot
(GIT_WORK_TREE=/path/htdocs git checkout -f) on update
Before gitolite, I would just update the hook for the specific repository.
Gitolite documentation mentions that all hooks should be at hooks/common so I don't understand how it works.
What should be the name of hooks, where it should be located and how it's structure should be changed (if it should)?
Update July 2013: what follows is for gitolite V2 (or 'g2'), which was the version used by the OP at the time (November 2011).
Update August 2013, with the latest gitolite 3.x:
You now have official specific repo hook:
it's basically just creating a symlink in <repo.git>/hooks pointing to some file inside $rc{LOCAL_CODE}/hooks/repo-specific (except the gitolite-admin repo)
All hooks in gitolite/hooks/common are replicated in all repositories managed by Gitolite, as detailed in the hook propagation documentation.
That means your hook script must take specific action depending on the repo which execute said hook.
You can either use the $GL_REPO variable (which gitolite set and pass to all its scripts for any git command it receives).
Or you can use some git configuration registered on the gitolite server, like the mirroring hook does. See the post-receive.mirrorpush hook.
The OP Eyal R adds in the comments:
But I still don't understand how it is done (I understand that $GL_REPO is used to determine which repo I am updating but I'm missing the practical part).
I have created a file called post-receive.test with echo "test", put it in $HOME/gitolite/hooks/common, ran gl-setup, ran push from workstation - nothing happens (no "test" output)
To which I replied:
The hook should appear in the hook directory of your repo on the gitolite server as a link, linking back to the .gitolite/common/hook. Note that it should be in $HOME/.gitolite/common/hook, not /gitolite.
The OP confirms the missing dot was the issue.
The process to add an hook is detailed in Hook propagation in gitolite, and their usage in "Using Hooks".
This is a fairly common need for someone using gitolite, and appears to be a little difficult to tie up loose ends when being not a very advanced user (at leas it was for me).
Following stackoverflow's and gitolite's links back and forth can be a little confusing. These are my conclusions and the path I followed to be able to achieve this.
As #VonC mentioned creating repository specific hooks is already possible since version 3.5.3.1 (github link)
Update/Upgrade Gitolite
The first thing you should do is update your gitolite repo. So ssh into your server that is hosting gitolite and move to the location where gitolite is installed (usually /home/git/gitolite) as the git user (usually git)
Example:
$ ssh myusername#devserver.com
$ sudo su - git
$ pwd
/home/git
$ cd gitolite
Then we have to upgrade gitolite. To do so, first we need to update the gitolite repository
$ git pull
Then we have to repeat the install command (make sure you use the same arguments as before)
$ ./install
And finally run the setup again.
$ gitolite setup
If that doesn't work, you probably haven't set up gitolite executable in your PATH, so you could do something like this:
$ src/gitolite setup
Gitolite Settings (The "RC" file)
This was one of the parts that confused me the most, but it ended up it was pretty straight forward.
The famous "rc" file is located at git's home directory /home/git/.gitolite.rc. There make sure you have a variable called LOCAL_CODE, you should see something like this on that file, if not, add it.
LOCAL_CODE => "$ENV{HOME}/.gitolite/local"
And in the "commands an feature to enable" section you should make sure that repo-specific-hooks is available, if not, add it.
ENABLE => [
# COMMANDS
# These are the commands enabled by default
'help',
'desc',
'info',
...,
...,
...,
'repo-specific-hooks'
...,
...,
...
]
Here is the link to the documentation
Writing Repository Specific Hooks
Finally, in your local gitolite-admin repository create the following directories hooks/repo-specific under the directory you just set in the LOCAL_CODE variable, for example:
gitolite_admin/local/hooks/repo-specific
After that you can actually add your hooks scripts to that location and manage them through the gitolite conf file as stated in the documentation. Make sure the scripts are executable.
repo foo
RW+ = #all
option hook.post-receive = deploy
Again, I hope this helps some of you guys.
Cheers!