Hi all,
I am new to gitlab and have just installed the community edition omnibus on my ubuntu machine and changed the default repo storage area to ‘/mnt/git-data’ per the following instructions and editing ‘/etc/gitlab/gitlab.rb’ and changing the default:
https://docs.gitlab.com/omnibus/settings/configuration.html
I ran the “sudo rsync -av /var/opt/gitlab/git-data/repositories /mnt/git-data/” command to sync all files and then deleted the original folder and underlying files for sanity under /var/opt/gitlab/git-data and I can successfully run git-lab reconfigure afterwards, and the folder owner of git-data folder under /mnt/git-data is the git user; all in line with what it should be.
I have created a first project now with a readme.md file in it’s repository as the first file with a couple edits to force more versions. However, when I poke around in /mnt/git-data, I cannot find any versions of this file or frankly anything that looks like git’s versioning of file. Why can I not see any evidence of my new project’s repo?
Bump. Could someone please respond? It is very important that I am able to save my repositories in a custom path.
Hi,
please don’t bump a topic, we all have our day job and sometimes answers may take a while.
Git repositories on the server are so-called “bare repositories”, where you don’t have a local file checkout. Instead, the history is stored in Git objects without any working directory. That’s basically the same you can see in a local cloned repository underneath the .git repository.
A bare repository is commonly used on Git servers, where many collaborators may clone from, and push into.
In order to access your data, you need to clone/pull the repository from the server. Or you verify it against the REST API from GitLab.
Or, if you exactly know what to query, look into git show.
Here’s a sample from production:
cd /var/opt/gitlab/git-data/repositories/packaging/rpm-icinga2.git
git --no-pager show master:icinga2.spec
Cheers,
Michael
Thank you @dnsmichi! You’re answer is very helpful information. However, I can see from your command that you at least be able to see the repo elements in your git-data directory. I am unable to, yet gitlab is able to start with the following in ‘/etc/gitlab/gitlab.rb’:
git_data_dirs({
“default” => {
“path” => “/mnt/git-data”
}
})
And the original git-data is gone, so since Gitlab is starting up successfully with no errors, it should be seeing /mnt/git-data correct? Here is some output from /var/opt/gitlab/ for sanity:
/mnt/git-data/repositories# ls /var/opt/gitlab/ | grep gitlab-
gitlab-ci
gitlab-exporter
gitlab-rails
gitlab-shell
gitlab-workhorse
So, I cannot perform your cd step.
The output of /mnt/git-data/repositories/ is as follows:
/mnt/git-data/repositories# ls -al
total 20
drwxrws— 4 git root 4096 Dec 16 21:39 .
drwx------ 3 git root 4096 Dec 10 14:17 …
drwxr-sr-x 4 git root 4096 Dec 7 10:51 +gitaly
-rw------- 1 git root 64 Dec 7 09:58 .gitaly-metadata
drwxr-s— 5 git root 4096 Dec 11 08:29 @hashed
How can I see the files you see?
Hi
ah. We have installed GitLab some years ago where Gitaly didn’t exist and never have migrated since.
Gitaly is the service that provides high-level RPC access to Git repositories. Without it, no other components can read or write Git data. GitLab components that access Git repositories (GitLab Rails, GitLab Shell, GitLab Workhorse, etc.) act as clients to Gitaly. End users do not have direct access to Gitaly.
So to speak, you’ll need to use a client to interact with Gitaly’s RPC interface. That is for example the REST API.
Likely the git repo data is somewhere stored underneath Gitaly’s storage and hashed repo names. But to avoid that I’d go straight with high level user APIs or even git clone.
Besides, there are some “rugged” calls available for client developers, yet I don’t really understand the things behind it. Bring back a subset of Rugged calls under a feature flag (#57317) · Issues · GitLab.org / GitLab FOSS · GitLab
Here’s more on the rationale for Gitaly itself: The road to Gitaly v1.0 (aka, why GitLab doesn't require NFS for storing Git data anymore)
Cheers,
Michael
Thank you for the extensive and detailed reply @dnsmichi . Using it, i verified my understanding by running a du -sh command on the git-data/repositories directory before and after a bunch of commits and pushes to my repo. I saw the size go up a logical amount of kilobytes. I then used the find command to recursively search that directory for the most recent updated files and indeed, I saw a bunch of files with long hex names corresponding to my commit times, all under the gitaly folder. So, this was good enough for my sanity check that i moved the default repository storage folder correctly, and for my own understanding. And of course, my git clone is working properly on all my clients and I can see all my branches, tags, and files. Thank you!
1 Like