I have some scripts that I call from a common hook of gitolite, I want to manage them from the configuration directories of the admin-repo repository so I can modify them more easily and they will be versioned also.
I have tried by adding a new directory and by tracking it with git add, but it does not work as expected. Maybe gitolite has some way to do this but I have not found any information on how to do such a thing.
Note: the following is for Gitolite V3 or g3 only.
You can add/manage them in their own directories, namely the "hooks/common" sub-directory if the gitolite-admin (create it if it doesn't exists).
That directory will appear in your Gitolite server in ~/.gitolite/hooks/common, and if you define a LOCAL_CODE rc variable) pointing to it, it will be taken into account.
You might need to follow the push of the gitolite-admin repo by a gitolite setup --hooks-only on the server though.
Related
We are using git for source code management and own a SLES server which we use as a remote for our git repositories. We access git with SSH, using the real user names, not the single git user alternative, which would authenticate through the authorized_keys file of the git user.
A while ago, I figured out a problem with pushing to our remote. One user was able to push while another user was not able to push. So I began to analyze, why certain users are not able to push. I finally figured out what the root cause was: A bare repository on the remote always has a directory named objects, where commits are finally saved through the push process. This directory contains sub directory with the first two characters of a hash value. If a directory has not been created yet, it is created during a push to the remote.
And here's the mysterious thing about it, I cannot explain to myself: Some users create these directories with permissions rwxrwsr-x, while other users create them with rwxr-swr-x. As you can see, the set-gid bit is set, which is OK. But I cannot really explain why some users create directories with group write permissions while others do not.
The pitfall here is that if user A creates a directory without group write permissions and user B calculates a hash value that begins with the two characters of the already created directory of user A, user B cannot place files (commits) in that same directory, which makes it impossible to push to the remote for user B.
I have already watched out for default umask settings, that are probably different, but could not find different settings. All users on our SLES server have the default mask 0022, which will result in files being created with rw-r--r-- and directories with rwxr-xr-x. And this is the second mystery: Why do some users create directories in git with rwxrwsr-x (which is correct for git and intended), despite of the umask 0022?
Has anyone hints for me for further troubleshooting? What I want to achieve is that users create the objects sub directories with rwxrwsr-x.
Set
git config core.sharedRepository 0660
at the server repo. See the docs.
Currently, I am tracking my repository with inotifywait. And it supports only flat files, so I created non-bare repo actually with git.
But I decided to go to Gitolite and I can’t see anything about creating non-bare repo. Is there is an option?
inotifywait waits for changes to files.
If you want to monitor changes at the server level (where gitolite operates, behind ssh), you will need to add a non-update hook, typically a post-receive one, which will checkout the bare repo somewhere monitored by inotifywait.
I am trying to add an owner name of repo that shows up on gitweb.
I can't seem to find anything on the net.
Anybody knows how to do it?
I know to change the description of repo by ssh git#server desc reponame "string"
But, there seems nothing for owner.
Thanks
First, gitolite and gitweb are two different tools:
gitolite is an authorization layer in perl (which can be integrated to gitweb).
it needs to be installed in addition of Git, and be called from one of the listeners (httpd or sshd) which does the authentication.
gitweb is a web interface, part of the Git distribution.
A repo as stored on a Git hosting server is not "owned" by a user.
It only has in gitolite a list of users who are authorized to push to it.
The gitweb.perl perl script does try to get the ownership information, based on, for instance, a git config owner property attached to the repo. Or from the folder owner.
None of those information are native to a Git repo hosting server, and you need to make sure the right owner is registered somehow (with, for example, adding that config to the repo, which can be set with Gitolite)
In any case, you would need to make sure $omit_owner is not set to 1.
I want to add my project to a subversion repository. The project folder contains a symlink to a folder containing thousands of txt files that I don't need to add to the svn repository. I DO want the symlink-folder to show up when I checkout the code, however.
It looks like I can use svn addprop svn:ignore symlinked-folder to ignore the folder, but then I'll have to add that symlinked folder to every working copy I check out before everything will work.
Is there a proper way to do this?
Perhaps there is no way to deal with this, since a symlink is a filesystem artifact. Is there a better way to handle this situation?
CONCLUSION - EDIT
After all this investigation, I committed the symlink-folder by accident and SVN added it to the repository without adding any of the files within it. Upon checkout, everything works fine. The symlink-folder checked out and works.
I am using assembla to manage my SVN repository, so that might have something to do with this success.
The answers above are right, your symlink won't work if you check out the repository on windows.
But if you're aware of that and you don't care, you can add just the symlink without its contents:
svn add -N your-symlink
man svn add here
I believe you are correct, imagine if a user checked out your repo under Windows - how would SVN create the symlink when the underlying OS doesn't support it?
Is the target folder that you are symlinking to under version control? If so, you can make use of the svn-externals property.
You are right, it doesn't make sense to add a symlink to a repository. What would happen if someone checked out the source on a machine that didn't have access to the folder the symlink points to?
One way is to structure your repository so that you can check out the codebase without having to check out documents. E.g.:
Trunk
Tags
Branches
Documents
So you only check out the trunk or branch that you are working on, and when you require it you can check out the documents.
Alternatively, use a project management tool like Redmine to store your docs. It can integrate with svn as well so you can view your repository and manage permissions through it.
I have an existing bare git repository located in /home/myaccount/git/project. I am currently using it over ssh from my local machine without any problems. I want to add a second user on the server which only shall access to this git repository (maybe move the repo outside my account folder?). How? Using latest version of git and ubuntu on slicehost.
I have this setup:
user: sleepyhead
user: developer1
group: git. both sleepyhead and developer1 are members of this group
repository /home/sleepyhead/git/project1
I want to:
move repository to a proper place, either /home/git/project1 or /usr/local/git/project1. What is recommended?
developer1 should permissions to read and write project1 with git. no other permissions should be given.
I do not know how to properly set the permissions and to restrict developer1 to only have access using git to project1.
Have him create a ssh keypair and send you the public key.
Add the public key to your ~/.ssh/authorized_keys file, and add the command="..." option to limit it to the git-shell - see this link for an example.
Orip's answer is probably all you need. If you want something a little more automated you might want to look at gitosis
You will also probably want to have both of those users in the same user group, and to make sure you have group-write privileges on the repository.