I've been through the extensive gitolite documentation over and over again. This is my configuration :
Git user running gitolite, while I installed Gitolite as another user, which had root privileges. I installed using the gl-system-install method.
Now, I see two copies of hooks/common directory /usr/local/share/gitolite/hooks/common and /home/git/.gitolite/ (and I intend to work with the first one for system wide implementation)
The gitolite-source is located at /home/user/gitolite-source
I've put in some dummy hooks in the /home/user/gitolite-source/hooks/common/ directory (post-udpate, post-update.secondary, post-receive and post-commit). All of these have exec bit set.
If I edit the update hook in this directory and re-run the setup again, the newer update hook (in existing repos) is sym-linked to the update hook in /usr/local/share/gitolite/hooks/common.
But even though any newer hooks in the source/hooks/common directory are copied over to both the hook locations, newer sym-links do not appear in my existing repos.
In short : gitolite copies its own hooks, but neglects mine.
Any idea why?
I figured out the answer on my own.
I was re-running the gl-system-setup over and over again in hopes of making those sym links created for me under each repository, while it was the gl-setup that did it.
But re-running gl-setup did not work either. (It gave strange parse errors). So I decided to just remove all the gitolite-hooked sentinel files, and push an update to the gitolite-admin repo, which copies hooks over if it does not find the gitolite-hooked file.
Related
I'm collaborating with a few other people on a Drupal website which we are version controlling Git. We setup a local Git repository containing our commits.
After a colleague pushed some updates and I fetched and merged into my local dev branch, I began experiencing the following problems:
user#server:/var/www/Intranet/sites/intranet/modules/custom$ git checkout dev
error: The following untracked working tree files would be overwritten by checkout:
themes/bigcompany/panels/layouts/radix_bryant_flipped/radix-bryant-flipped.png
themes/bigcompany/panels/layouts/radix_bryant_flipped/radix-bryant-flipped.tpl.php
themes/bigcompany/panels/layouts/radix_bryant_flipped/radix_bryant_flipped.inc
Please move or remove them before you can switch branches.
Aborting
The issue above typically shows up when I try to checkout into other branches which fails and I am effectively trapped in my current branch.
Referring to this question, there is a suggestion my issue is related to the gitignore file. However, my .gitignore file has nothing indicating any part of my themes directory should be ignored as the following shows:
# .gitignore for a standard Drupal 7 build based in the sites subdirectory.
# Drupal
files
settings.php
settings.*.php
# Sass.
.sass-cache
# Composer
vendor/
# Migrate sourec files
modules/custom/haringeygovuk_migrate/source_data
As mentioned above, my attempts to execute git checkout into any branch fails with the message above. I decided to force it with the -f switch and successfully switched into my target branch but I lost a couple of hundred lines of code - which I'd love to avoid going forward.
I work on a Linux-Ubuntu VirtualBox which my colleagues prefer working in a WAMP setup and use the Git Bash terminal emulator for executing the Git commands. Could the difference in environments be causing these serious issues?
How can I resolve this issue?
Well, the situation is rather simple. You, in your current branch, don't have certain files under the control of Git, but at the same time, you have those files in your working tree. The branch you're trying to switch to, has those files, so git would need to override files in the working tree to perform checkout.
To prevent possible data loss, Git stops the process of switching the branches and notifies you that you should either add those files under the control of Git in a separate commit in your current branch, and only then perform the switch, or simply remove those files from the git way.
Likely you have chosen the second way. Generally you should "force" any operation only if you really understand what you're doing.
There is server running under CentOS with php-fpm and nginx on aboard. Two projects are hosted, one of them is primary, the second contains half of the primary project as symlinks and part corresponding to itself. Both projects are in git repos. The primary project works correct under Linux and Windows machines after cloning the repo. But the second project contains symlinks and it doesn't work properly.
I don't know what to do. It's important to save the symlinks, but how should we work with the second project on Windows? Some hooks with git (replace symlinks with files before pull)?
git converts symlinks to text files on Windows, since symlinks are available only on *nix environments, and msysgit doesn't take care of them by default.
You can create a post-commit hook to workaround them.
Check answers on git symlinks in windows, specifically this one where a user has given steps to handle the scenario.
You are looking for git submodules: http://git-scm.com/docs/git-submodule
I tried to search to find a solution.
but, I can't.
I installed gitolite. And it works well.
I can git clone on the local machine, and change gitolite-admin repo too.
But I want to use gitolite hooking.
followed this manual
http://sitaramc.github.com/gitolite/hooks.html
custom hooks
You can supply your own, custom, hook scripts if you wish. Install
gitolite as usual, then:
go to ~/.gitolite/hooks/common on the server and put your new hook
there now run "gl-setup" again You can use this procedure to install
new hooks as well as to update hooks that you had previously
installed.
So I tried to hook some basic shell script.
I put bash shell script on
~/.gitolite/hooks/common
and named it
update
update script file's owner is git, and excutable.
the shell script is like this..
#!/bin/bash
touch /tmp/$GL_REPO
and I execute
gl-setup mypubkey.pub
and then,
On my local git folder,
I modified some file, commit and push to gitolite server.
push works well. every file uploaded to the gitolite's repo.
but, hooking doesn't seems to occur. Nothing happened.
on the server's tmp directory, no file is created.
Did I forget something?
any comments plz...
You should realize that (from the "using hooks" page you mention in your question=:
The update hook is used in all repos and is critical to gitolite's access control
In other words, you cannot directly use an "update" script.
You must use the "hook chaining" feature of gitolite, in order to call your own update hook after the one of gitolite:
To run your own 'update' hook, just put it in a file called update.secondary and install it as a hook.
Gitolite's update hook will automatically chain to it, taking care to pass it the same 3 arguments the original update hook received from git.
In the end, the OP Jinbom Heo, rather than using "gitolite hook chaining", went with another hook:
I put post-receive file in /var/gitolite/hooks/common/ folder. And it works.
The doc "Where do I put my hooks" suggest rather to put those under the "user" location (~/.gitolite/hooks/common):
But the system location works too.
( /var/gitolite/hooks/common/ means, by the way, the OP chose the root method installation or the package one, with the default paths /usr/local/bin, /var/gitolite/conf, /var/gitolite/hooks)
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!
I am new to use svn and the company in which I work uses three levels (I don't know whether this is a correct word to use here) of svn. I mean the developers are provided a working directory on a testing server. When we commit, it goes to the dev server. When a manager commits it from there it goes to production server. I am a developer here and one of my files is giving error (conflict) when I commit from directory. Not only, but also it gives conflict when manager tries to commit. I am now given access as manager too but I am still unable to resolve it.
What I've tried till now:
svn update
svn delete
svn commit
It gives conflict on all of these operations.
Earlier on a simple error happened and the manager preferred to just delete file on dev, copy it manually and then commit from there. I don't know this may be a reason of this problem or not.
Please help me resolve this issue. I've read some things in read-bean book too but to no avail yet.
Thanks
Ok, here's the update. The actual problem is that a file (ex lib/a.php) used to be in my working directory as well as in dev and production servers. Now it was deleted by someone (using del command, not svn delete) from dev server. Now question here is how I add it again so that it becomes part of svn again. The simple svn add doesn't work.
Update 2
From one of the answers below I understood that its a tree conflict. Some searching brought me to http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html . Following the instructions, I took the backup of the file and then svn delete it from everywhere. Then I svn add it to my directory, commit it and tried to update dev and production. End result is that it doesn't go there. No error is shown either.
svn info in my directory shows complete info of the file but on dev and production it shows
file_name: (Not a versioned resource)
:S
Any more ideas please?
Alternatively you can take backup of the file ,then say svn revert filename insert you new code.Do a svn up just to make sure you do not have any conflicts,and then commit
Or
fix the conflicts in the file and then you can say svn resolved filename and then you can continue operations on the file
Update:If your file is deleted using rm or del command use svn revert filename to get it back and you do not have to add it again.Just put in your new changes and say svn ci -m"your comments" filename
svn revert will fetch back the last checked in copy into SVN and it wouldnt have your any changes made before the user had used del command
Update 2:After u say svn delete ,u need to commit it until u get the message Deleting filename with a new revision number.Then add the file using svn add command,then commit again.Once this is done you can check the svn info, let me know..
Use svn status command to know the status of the file
The only problem apart from this i can think of is this the directory may not have been added.Is this a new directory?
ah, the old tree conflict problem.
The issue is that SVN is letting you know that you're adding a file that used to be there but it cannot tell whether you're trying to delete it, add it or just update it! So it does the only thing it can - flags a conflict so you can sort it out and fix it. Its basically a conflict on the directory level (rather than a conflict of a file's contents).
What you do is resolve the error (as others have pointed out), then update the directory to get the original file back, then commit your changes. Note that the file was never deleted from SVN - its still in the repo, and if you checkout out a new WC, you'd get the file.
Try to resolve the conflicts then commit again:
svn resolve --accept working