I have a test VM with Debian Wheezy and no ruby installed. Gitlab 6.9.2 has been installed using the provided installer which brings an embedded ruby. Now, I want to import some old repos into Gitlab, but I cannot find the correct procedure. I think it should be this way:
su - git
export PATH=$PATH:/opt/gitlab/embedded/bin
cd ~
bundle exec rake gitlab:import:repos RAILS_ENV=production
Though, I only get the error "Could not locate Gemfile". I have tried several other ways, also installing Debians ruby, searched multiple Google and StackOverflow results, but I couldn´t get it to work.
You should first place the bare repos in the repo dir. The default path for omnibus is /var/opt/gitlab/git-data/repositories/<namespace>. Then you just run the rake task:
sudo -u git -H cp -r my-project/.git /var/opt/gitlab/git-data/repositories/<namespace>/my-project.git
sudo gitlab-rake gitlab:import:repos
See invoking rake tasks and the import mechanism.
Edit: Sent an MR upstream to include this info in the readme.
I have run into same issue with "Could not locate Gemfile". So I searched for Gemfile and tried several folders. Until it worked.
The solution is related to Gitlab from source (or in my case it run inside offical docker container).
Place your .git bare repository (or several of them) in
"/var/opt/gitlab/git-data/repositories//my-project.git"
switch to user "git".
su git
Try if you have correct PATH by just "rake". If not available, extend your PATH:
export PATH=$PATH:/opt/gitlab/embedded/bin
after that switch to the shell were the rake command to import your bare projects will work and do the import.
cd /opt/gitlab/embedded/service/gitlab-rails/
bundle exec rake gitlab:import:repos RAILS_ENV=production
Output will be similar to this:
Processing raspberry/apollo-web.git
* Created apollo-web (raspberry/apollo-web.git)
Processing raspberry/apollo-web.wiki.git
* Skipping wiki repo
Processing dhbw/dhbw-prototyping-node-rest-course.git
...
EDIT:
Ok I was happy a bit too early. Although the ouput says it was imported. On the Web GUI no new projects.
I will investiage further...
Related
I've got an electron app (Electron v17.4.10) running on macOS Monterey (v12.5) and on startup it attempts to perform the command git lfs install. It does so by using the Node child_process package's spawn command to invoke a direct call to a standalone git executable.
When the electron app is installed, it provides its own version of git that isn't added to the PATH to prevent interfering with any git versions that may already be installed. The standalone version of git (v2.33.0) has the folder structure shown in the image below and the git-lfs binary (v3.2.0) is contained within /PortableGit/git/libexec/git-core/
Standalone Git Directory Structure
The full command executed is:
"/Applications/MyApp/Utilities/PortableGit/bin/git" lfs install
And the output is:
git: 'lfs' is not a git command. See 'git --help'.
The most similar command is
log
How can I get the standalone installation of git to recognize the subcommand lfs without placing it on the PATH? Is having a self-contained git package like I've described even possible? Or should I abandon the approach and ensure git is installed properly on the target machine?
The answer to this problem is that Electron's process.env is different from the target system's env. So while Git will look for submodules on the PATH, the PATH used in the Terminal will be different from the PATH used by the child process.
Appending a ':' followed by the path to where the git-lfs binary is stored to process.env.PATH will allow the standalone git installation to properly identify git-lfs subcommands.
I.E.
process.env.PATH = process.env.PATH + ":" + "path/to/git/lfs"
So, I'm trying to install gitlab on a subdirectory. A lot of articles online suggest it is now possible to do so.
I installed omnibus-gitlab but it didn't seem to contain the files required to make gitlab run in a subdirectory like application.rb and stuff. Did a little research and discovered it is not yet supported on omnibus.
So why the differences? I actually thought they were all different ways of getting the same thing. My question again: difference between cookbook, omnibus and normal manual installation. Thanks!
Cookbook : the installation is done by Chef recipes
Manual : you install all the components one by one, manually, with a lot of pain and suffering
Omnibus : The installation in simplified with a .RPM (red hat) or a .deb (Debian), much more simple.
The results are differents: with a manual install, the home dir of gitlab will be somehting like /home/git/... while it will be /opt/gitlab/... in omnibus. Also, the commands to manage your GitLab instance are a little differents. By example, in manual install to seed an external DB you have to type sudo -u git -H bundle exec rake gitlab:setup while gitlab omnibus will need a sudo gitlab-rake gitlab:setup.
From what I tested, they all leed to the same GitLab features, but with a different way to manage it.
Now for the subdirectory (it doesn't works for me, but that's what the documentation say) : after an omnibus install, modifiy the non_root_url in the following files :
/opt/gitlab/embedded/service/gitlab-rails/conf/gitlab.yml
/opt/gitlab/embedded/service/gitlab-rails/conf/application.rb (read the comments at the bottom of the file)
/opt/gitlab/embedded/service/gitlab-rails/conf/unicorn.rb
/opt/gitlab/embedded/service/gitlab-shell/config.yml
And then restart GitLab. I repeat: that's what the gitlab's doc say, but it doesn't works for me. In my case it just create a redirection. Look:
#gitlab is configured to run in subdirectory "/gitlab" :
curl -v http:127.0.0.1:3000/gitlab
----> Error 404
curl -v http://127.0.0.1:3000
----> <html><body>You are being redirected.</body></html>
I've been using git along with a project in order to have version control for quite some time now. But all of a sudden, it stopped working! I noticed that while pushing new changes, because I received this message:
/home/user/bin/git/bin/git: No such file or directory
Also, whereis command is unable to find where the program named git is present:
> whereis git
git:
Any idea on how I can solve this?
It looks like you have a dead link to a local version of git (which you might have removed?) in your $PATH. Try which git or find / -lname /home/user/bin/git/bin/git to spot it.
"Failed to find 'git' on your PATH. Please ensure 'git' is executable by the Go Server and on the Go Agents where this material will be used."
I'm getting this when attempting to use GIT when creating a new build pipeline.
I'm not that experienced with Linux to know how to debug this and I can't find anything in the docs or via a google search.
GO was installed as root, so was GIT, the server has been rebooted since and I can run git in bash. "which git" shows that it is in /usr/bin. "export $path" shows that /usr/bin is in the PATH variable.
Can anyone recommend anything else to try?
Thanks.
The Go server and agent runs under user 'go' and therefore you will need to ensure git is in path for this user.
Change the user to go. If you get a prompt for password, put the password of the current logged in user.
$ sudo su - go
Then check if git is in path or simply check for the version
$ which git
$ git --version
If you don't get expected output for the above commands you might have to provide git executables to the user 'go', that is, you will need to add git in this user's PATH. Alternatively, you can provide the path in /etc/default/go-server
export PATH=$PATH:/path/to/git
I recall having this problem too, for me it was related to a local git repository that I did not share with the git daemon. Running the repository with the git daemon solved this problem for me.
URL for me starts with git://localhost, not sure if http will work too
i have a weird issue. Im using TortoiseGIT (Win7) and my repositories are placed on a vritual server (Debian), where im using gitolite and SSH keys.
I can clone the repository to my PC, i can run Fetch, Push, Commit, Sync .. everything, but when trying to Pull the changes from server Pushed by other contributor, the following error appears:
git.exe pull -v --progress "origin"
fatal: 'pull' appears to be a git command, but we were not
able to execute it. Maybe git-pull is broken?
git did not exit cleanly (exit code 128)
I don't understand, why just the pull command is not working .. thanks for any help.
I can make a clone of the repository, with the contributed changes .. but can not Pull the changes to created repository on my PC.
I encountered this same issue after changing the git Bash executable sh.exe to be always run as administrator (to get round another problem). It then left git unable to access it under certain scenarios and caused various "Maybe git-* is broken?" errors. Perhaps this might help someone...
Uninstalling old Git and reinstalling the latest build fixed this issue for me.
Here's a link to the installers
Link to get installers
My exact error message was
C:\Program Files (x86)\Git/libexec/git-core\git-pull: line 304: exec: git-merge: not found
fatal: 'pull' appears to be a git command, but we were not
able to execute it. Maybe git-pull is broken?
The error message is very much linked to Git, and comes from help.c:
static const char bad_interpreter_advice[] =
N_("'%s' appears to be a git command, but we were not\n"
"able to execute it. Maybe git-%s is broken?");
That is similar to issue 40 (of another GUI, here terminal-ide).
In that case, it was due to the remote Git installation, which was incomplete
(Comments 3 of issue 19)
git-merge was also missing from install, can be fixed with
$> ln -s git git-merge
in system/bin/
The resolution might not be exactly the same in your case, but it could be related to a faulty Git installation.
I see that you're able to run "git fetch". If you can also run "git merge", running the sequence "git fetch" followed by "git merge" will accomplish the same thing as "git pull".
Source:
http://git-scm.com/docs/git-pull