Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We used to keep our Nagios config up to date through SVN, with users commiting their changes and a script running every 15 minutes. The script checked for updates, then checked those updates parsed the config check, then reloaded the config. Nice and simple, did the job perfectly.

We recently moved to GIT as part of a wider migration towards GIT for other projects and I'm having difficulty reworking this script to match.

Here is the original SVN version:

cd /usr/local/nagios
RESULT=`svn update | grep Updated | wc -l`
echo $RESULT
if [ "$RESULT" != "0" ]; then
    /etc/init.d/nagios reload
fi
cd -

And here is my best efforts so far with GIT:

cd /usr/local/nagios
RESULT=`git pull 2>&1 | grep Unpacking | wc -l`
echo $RESULT
if [ "$RESULT" != "0" ]; then
    /etc/init.d/nagios reload
fi
cd -

The problem I'm having is I can't seem to get the output parseable so I can match against it. I thought about going a different route by examining the most recent commit in the local working copy, and then checking if the remote most recent commit was different. I can't figure out though how to get this information.

I'm pretty new to GIT and this is driving me nuts, so my huge thanks in advance for any assistance!

share|improve this question
    
    
the learning curve on git is fairly high, but it's well worth it. –  Sirex Feb 3 '13 at 23:59
    
@Sirex I completely agree so far, the workflow is so much more powerful. –  SimonJGreen Feb 3 '13 at 23:59

4 Answers 4

up vote 3 down vote accepted

You can check if the tip (a.k.a. HEAD) of the local branch changed before and after you pull.

cd /usr/local/nagios

before=$(git rev-parse HEAD)
git pull
after=$(git rev-parse HEAD)
if [[ $before != $after ]]; then
  service nagios reload
fi
share|improve this answer
    
Thanks, used the principles of this and works like a charm. –  SimonJGreen Feb 4 '13 at 22:20

If you want to know whether there are new changes to fetch, you can compare the output of the following commands:

$ git show-ref origin/master     # <-- Where this repo thinks "origin/master" is
5bad423ae8d9055d989a66598d3c4473dbe97f8f refs/remotes/origin/master
$ git ls-remote origin master    # <-- Where "origin" thinks "master" is
060bbe2125ec5e236a6c6eaed2e715b0328a9106    refs/heads/master

If the hashes differ, there are changes to fetch:

$ git remote update
Fetching origin
...
From github.com:xxxx/yyyy
5bad423..060bbe2  master     -> origin/master
share|improve this answer
    
This is great insight on how git works, but git pull is a handy shortcut for all that. There is no need to overcomplicate things. –  chutz Feb 4 '13 at 8:55
    
Not quite a shortcut for all of that; git pull will do a merge as well, and only on to the current branch. The above will obviously work for non-current branches, and allows you to use git reset instead if you've rebased and don't want to scatter merge-commits everywhere, etc etc. –  nickgrim Feb 4 '13 at 10:36

You could use the post-merge hook, which will trigger only when there is a merge on the client side and if there are no conflicts.

Content of the post-merge:

#!/bin/bash

/etc/init.d/nagios reload

Copy the file in .git/hooks on the client side and don't forget to chmod u+x post-merge

share|improve this answer

Use the checksums displayed by git log. For example:

cd /usr/local/nagios
git fetch
if [ "$(git log | head -n 1)" != "$(git log origin | head -n 1)" ]; then
    git pull
    /etc/init.d/nagios reload
fi
cd -
share|improve this answer
    
git log origin gives me fatal: ambiguous argument 'origin': unknown revision or path not in the working tree. –  SimonJGreen Feb 3 '13 at 23:51
    
it'll be the name of your remote i expect. git remote -v to see that. Origin is the default name used though. –  Sirex Feb 3 '13 at 23:58
    
It does say origin. There's 2 entries though, one with (push) and one with (fetch) could that be the problem? –  SimonJGreen Feb 4 '13 at 0:01
    
@ichimonji10 you can also compare git rev-parse HEAD and git re-parse origin/HEAD which is a little easier. –  Sirex Feb 4 '13 at 0:04
    
@simonJgree odd. two entries is normal per remote. You can make pushes go to different places than fetches come from, but most people don't need that. –  Sirex Feb 4 '13 at 0:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.