I was set git server with gitolite and I have finished it Now. But One question truble me. I am set gitolite with both ssh and http mode.
I use the gitolite-admin.conf to control the repo and user's auth. I followed the instruction: modify the conf, git add it, git commit it and git push it. But It does't work.
In Client I can't clone the new repo I have add in the conf
this is my conf
the default repo 'testing' is working regularly
That is because gitolite honors gitolite.conf very strictly. You need to specify these lines in the conf file
repo #all
RW+ = #all
This will allow you to do operations on all the repos. But, you need to understand that when you specify #all in repo section, that means every repo falls in this rule. So, even if you have something like this in the file:
repo foo
R = xyz
gitolite ignores it because it sees that the repo foo belongs to #all. So, in order for clone operation to work, you need to specify READ permission to all the repos, something like this:
repo #all
R = #all
And then you need to add all the permissions to the other repos as well, otherwise you will only be allowed to read the other repos and not write them.
Related
I am using git from a long time but never set it up on server. Refereeing to this Git: move existing repository from PC to server, clone from server
I have initiate a bare repo on server but while adding origin in local
"git remote add origin server:path/to/repo" i have no idea what to add here. My site is getwalkwel.com and user is getwamld
Thanks
Origin is the name of a remote which is typically created automatically when you clone a repo from another repo. The origin reference in the cloned repo will be created to point back to the repo that was cloned from.
In your case, where the bare repo was actually created later from your working repo, you will create origin in your working repo to point back to your new bare repo.
This is done with:
git remote add origin /barerepo/fullname
If your bare repo is going to line on a different machine, then you need the URL to reach the repo instead of just a file path.
For instance, you might have myuser#myserver:path/to/repo
Bare repository in Git is a repository which only contains version control information only in fact this will not have .git sub-directory or any working files.
This kind of repository is helpful when you need to share or divide your work between few people for example in work environment you and your team mates are working on same project and you all need to see changes and all needs to do push to repository in this case this repository is more useful.
You can add the remote repository to local git repo
$ git remote add origin ssh://myserver.com/var/git/myapp.git
pushing to remote repository:
to push our local master branch to the origin's master branch. You can do that using the git push <target> <local> command.
$ git push origin master
click here for more information on how this works
Typically, in Mercurial, I create a new project by:
Create a new remote repo
Clone the repo locally
Make changes to the local repo
Push those changes to the remote repo
The "remote repo" here is actually our "central/originating" DVCS server (http://ourhg.ourorg.example.com, etc.).
I am now in a situation where I had to use a code generation tool to produce the source code for a simple web app. So the source code exists before the remote repo exists on our hg server. I'm looking for the exact shell commands I need to execute to get this properly pushed to the remote repo.
I believe it should be something like this:
Use the code generator to generate the code, say, at /home/myuser/myapp.
Initialize an hg repo for myapp locally on my machine (hg init)
Add the generated source code for myapp to this local repo (hg add, then hg commit)
On ourhg.ourorg.example.com, create the new remote repo (manual steps)
???
Push the changes sitting in my local repo to the remote repo (hg push)
I know there is something missing in between Step #4 (creation of the remote repo) and Step #6 (pushing to the remote repo). There surely needs to be some "connection" step where my local repo and the remote repo realize they represent the same project/source code/etc. This is my hangup here, so I ask: what is Step #5?
what is Step #5?
Discover URL of this repo. Because it's empty repo, you can don't worry about "related|unrelated"
There's nothing you need to do to associate them. You can do hg push URL_OF_REMOTE on your local and it will work. If you don't want to have to provide the URL each time you can edit (creating if necessary) .hg/hgrc in the repo and set the default= value in the [paths] section. Something like this
[paths]
default=URL_OF_REMOTE
That's optional though.
Just use your origial steps, with caveat:
Create a new remote repo
Clone the repo locally (this will set default path of local to remote).
Make changes to the local repo (Use the code generator app to generate the code in the local repo).
Push those changes to the remote repo.
With this flow, you don't have to manually update the path to the remote repo.
I cannot find my project files on the server gitolite is running.
Basically, I built a git server using gitolite on a CentOS 6.2, and I created a new repository,I can successfully clone, pull, commit and push files to this new project, but when I logged in this server, trying to find my project files on it, I could not find them. the repository is in /home/mygituser/repositories/myproject.git/ , but none of my pushed files can be found any in there.
Is gitolite keeping the actual project contents somewhere else or is there a way to config and seperate project contents and its repository?
This is driving me crazy, any help will be highly appreciated.
Gitolite operates with bare repositories.
A bare repo has no working tree, meaning no files.
That is why, by the way, your repo root directory ends with .git: it is a naming convention to reference bare repos.
See "Git push only for bare repositories?" for more.
Your repos are managed by default on:
~git/repositories/myrepo1.git
~git/repositories/myrepo2.git
Generally, you don't need to look to the content of a repo while being on the server: you simply clone it on a client and look it there. (the clone won't be a bare repo by default)
You could clone it on the server, if you have a proper ~git/.ssh/id_rsa(.pub) key declared as a user in the gitolite.conf file.
It is what I do, as a test, after installing/updating gitolite on my server.
That works because of my local ssh config file:
Host gitolitesrv
Hostname localhost
User #USERNAME#
Port #PORT_SSHD#
IdentityFile #H#/.ssh/gitoliteadm
So I have a ~git/.ssh/gitolite(.pub) private and public key dedicated to gitolite admin, which I can use locally on the server to clone gitolite repo if I want.
That is because I use that same key to setup gitolite:
GITOLITE_HTTP_HOME= gitolite setup -pk "${H}/.ssh/gitoliteadm.pub"
If you have a similar setup, you can then clone any repo on the server:
git clone gitolitesrv:gitolite-admin "${gtl}/ga"
I have got a gitolite v2 installed on my company's server, and now I have to administrate it. Since it's really chaotic there I decided to install a new one, now it's v3. I have around 8 repositories what I want to move to the new install.
I don't need the old .rc file or any configurations, just the (working!) $GIT_HOME/repositories/*.git
What I tried: (found it while searching for solution)
copied all $GIT_OLD_HOME/repositories/*.git to $GIT_HOME/repositories/*.git (except gitolite-admin.git and testing.git)
then I updated the gitolite-admin.git/conf/gitolite.conf (by cloning and pushing back changes) with this kind of entries:
repo myrepo1
RW+ = #all
Now if I want to clone anything other than gitolite-admin or testing, it sais:
FATAL: R any myrepo1 myusername DENIED by fallthru
Few things I've checked:
ls -l $GIT_HOME -> gitolite:gitolite it's ok I guess since gitolite is the user I want to use
I did the same for all entries in the repositories directory and the permissions are the same.
I was googling for a solution however I didn't find any that fits my case. If you can help me or suggest me anything, please don't hold back :)
If you need any more details to find out the answer just tell me.
I had the same problem and upgrading did not work as it should so I used the following strategy - the bold text represents where was the step executed:
1- New: Install Gitolite (https://github.com/sitaramc/gitolite).
2- Workstation: In a new empty directory clone the gitolite-admin of the old version and rename it to gitolite-admin-old. Remove access to all users in gitolite-admin-old/conf/gitolite.conf except yourself - To disable anyone to do any change while you are migrating the repositories.
3- Workstation: Clone all repositories from the old Gitolite. git clone git#oldserver.com:repo.
4- Old: We already got what we want from the old repository. Disable old gitolite for good by adding exit 0 at the top of .gitolite.rc file.
5- Workstation: Clone gitolite-admin from the new server git clone git#newserver.com:gitolite-admin gitolite-admin-new
6- Workstation: Copy keys from the gitolite-admin-old/keydir to the gitolite-admin-new/keydir, add the repositories you want to transfer in the new gitolite-admin-new/conf/gitolite.conf with the user priviledges. add, commit and push.
7- Workstation: Push each required repository to the new server
git push --all git#newserver.com:repo
git push --tags git#newserver.com:repo
or
git push --mirror git#newserver.com:repo
8- Workstations: Change DNS or remote URL from each working repo.
Hope this helps
Make sure you have migrated your .gitolite.rc file, as described in the g2->g3 migration page
if you're migrating from g2, there are some settings that MUST be dealt with before running gitolite setup; please read the migration page and linked pages, and especially the one on "presetting the rc file"
The rc file for g3 is quite different from that of g2.
Or if you don't need the old one, as you mention, make sure the content of the default new one has appropriate values.
Make sure your new ~git/.ssh/authorized_keys file does contain a line with myusername in it.
The OP Attila Horvath confirms:
Note: nothing in any of the gitolite install/setup/etc will ever touch the data in any repository except the gitolite-admin repo. The only thing it will normally touch in normal repos is the update hook."
The last sentence just grabbed my attention, and it seems now that was the problem.
I first installed gitolite then copied there the repos, so I had to run again gitolite setup -pk mykey.pub and now it seems working!
I'm a complete noob when it comes to version control, but I recently started using GitHub to host some of my projects. I blindly use the command git push origin master to push changes to either of the two repositories. I don't understand how Git knows which repository to push to. I use the same command to push to each. Does the directory I'm in have anything to do with it?
Thanks for clearing this up for me.
A word of advice, "blindly use"ing anything is a bad idea.
git has a system of remotes which allows to specify URLs and transports to repositories other than the one where you're working. git push origin master pushes the current branch to the remote called origin as the branch master. You have a remote called origin. This is created by default when you clone a repository from a URL.
git remote add origin http://abc.com/def/ghi.git tells git the url that remote 'origin' points to.
When you use git push origin master, you aren't pushing to two repositories - you are pushing to the master branch in your repository who's name (alias) is origin.
Think of it like this:
I'm pushing my stuff to origin which is my repository address. What am I pushing there? My master branch.
If you are new and set git up yourself through git init, you probably aren't pushing to two repositories. Run this command to see what your remotes are:
git remote -v
This will return something like (assuming you have a git hosting service like github):
blahblah git#github.com:yourGithubName/fileName.git (fetch)
blahblah git#github.com:yourGithubName/fileName.git (push)
git#github.com:yourGithubName/fileName.git is your repository address. Some addresses are prefixed by https:// .
Git repositories contain a .git directory that contains metadata about the repository. That's what Git uses to determine where to push your changes.