top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

Facebook Login
Site Registration

Server side Git hook

+5 votes
61 views

I read this page about git hook: http://git-scm.com/book/en/Customizing-Git-Git-Hooks and I still have some questions. I have a git server with some bare repos and I want create something like a continuos integration test so, I need to run a script when someone push on these repos. Main problem is that these repos are "bare" and doesn't contains any file. there is a way inside my script to "extract" files from a bare repo or i need to create a working copy?

If i create a separated working copy, how can i pull out this working copy inside my script? I tried something like this, but seems not working
cd /home/git/workingcopy/myawesomeappgit pull./run_test.sh

posted Oct 28, 2013 by Jai Prakash

Share this question
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social Share Button

1 Answer

+1 vote

Use plumbing Git commands to . something like this:

$ mkdir -p /path/to/my/CI/dir && cd $_
$ export GIT_DIR=/path/to/a/bare/repo.git
$ export GIT_INDEX_FILE="`pwd`/.index"
$ git read-tree master
$ git checkout-index -a -u
...build, run test suite etc
answer Oct 28, 2013 by Deepak Dasgupta
Similar Questions
+1 vote

I have git version 1.8.4.msysgit.0 installed. If I run this as a daemon, where are the repositories located? (i.e. where do i do a mkdir foo.git; cd foo.git; git init --bare?)

How do I change where the (server) repositories live?

+1 vote

I want to understand the best practice of organizing the GIT repositories. Let's say:
1. We are a large bank with many line of businesses and tons of application.
2. Each LOB has a large number of applications.

How many repositories shall I use? How do we organize the applications inside one repository? Any reference?

+1 vote

I just had the bare vs non-bare repo concept smack me in the face. Painful way to learn things, but I won't forget it any time soon. Since my remote repos are no longer work trees, how can I keep two bare repos in sync? This is primarily for DR purposes.

Here's more detail in case it'll help:
I have two rhel6 systems running git 1.7.1 that will be maintaining OS and web configuration files for a variety of teams, once I get the bugs in my understanding ironed out. One git server is in datacenter A (prod) where most of the updates will be occurring. Appropriate people will clone the bare repo, make their updates and push it back. The other git server is at our warm DR site. While rare, updates to this server should be possible.

I need to be able to fetch changes from the production git server and apply them to the DR one. When I tried it straight, I got the expected "fatal: This operation must be run in a work tree"

I suppose I could hack out a script to pull the configs down to a temp repo and push them back up to the DR one (and vice versa), but that seems like a kludge. As flexible and seemingly well thought out as git appears to be, I have to believe there's a better approach.

Could someone clue me in on what I'm missing or how a generic DR process is typically set up?

+3 votes

I'm trying to import our team's old subversion repository to git, but I'd like to retain the commit history. I tried 'git svn clone' but that only retrieves commits from the last copy onwards.

Because the svn setup is really bad, there is no way I can reproduce the "stdlayout" structure that 'git svn' likes, or any other structure where the trunk isn't a just few versions down from a copy.

Is there a way to have 'git svn' not do "--stop-on-copy" when fetching history? I'm perfectly fine with getting a simple linear history (because trying to do anything else with our svn setup will put our sanity in danger), but I couldn't find any documentation on how to do so.

+2 votes

In coreboot we try to check for whitespace errors before committing. Of course a pre-commit hook is the way to go, but unfortunately it is not so simple (at least for me) as the following requirements exist.

  1. Only the files actually committed should be checked. That means running git commit -a, abort that and then running git commit some/file should only check some/file for whitespace errors.

  2. There are certain files that are allowed to have whitespace errors. In our case these are *.patch and *.diff files which by design seem to contain whitespace error.

Currently the whole tree is checked, which takes a lot of time. I tried to come up with a patch, but failed so far. Best would be to have

$ git diff --check --only-committed-files --exclude "*patch$"

where I could not find a way for the last to switches.

Currently, I would use

$ git diff-index --cached --name-only $against -- | grep -v patch$

and pass that list to some whitespace check program. Unfortunately that still does not fulfill the first requirement. What am I missing to solve this elegantly?

Contact Us
+91 9880187415
sales@queryhome.net
support@queryhome.net
#280, 3rd floor, 5th Main
6th Sector, HSR Layout
Bangalore-560102
Karnataka INDIA.
QUERY HOME
...