3

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!

Improve this question
3
  • stackoverflow.com/a/1139066/1068283 Commented Feb 3, 2013 at 23:28
  • the learning curve on git is fairly high, but it's well worth it. Commented Feb 3, 2013 at 23:59
  • @Sirex I completely agree so far, the workflow is so much more powerful. Commented Feb 3, 2013 at 23:59

4 Answers 4

Reset to default
3

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
Improve this answer
1
  • Thanks, used the principles of this and works like a charm. Commented Feb 4, 2013 at 22:20
1

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
Improve this answer
2
  • 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. Commented Feb 4, 2013 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. Commented Feb 4, 2013 at 10:36
1

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

Improve this answer
-1

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 -
Improve this answer
6
  • git log origin gives me fatal: ambiguous argument 'origin': unknown revision or path not in the working tree. Commented Feb 3, 2013 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. Commented Feb 3, 2013 at 23:58
  • It does say origin. There's 2 entries though, one with (push) and one with (fetch) could that be the problem? Commented Feb 4, 2013 at 0:01
  • @ichimonji10 you can also compare git rev-parse HEAD and git re-parse origin/HEAD which is a little easier. Commented Feb 4, 2013 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. Commented Feb 4, 2013 at 0:05

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.