<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Git on System Overlord</title><link>https://systemoverlord.com/tags/git.html</link><description>Recent content in Git on System Overlord</description><generator>Hugo</generator><language>en-us</language><managingEditor>david@systemoverlord.com (David Tomaschik)</managingEditor><webMaster>david@systemoverlord.com (David Tomaschik)</webMaster><lastBuildDate>Wed, 31 Aug 2011 22:53:21 +0000</lastBuildDate><atom:link href="https://systemoverlord.com/tags/git/index.xml" rel="self" type="application/rss+xml"/><item><title>Git On Your Web Server: A Security Reminder</title><link>https://systemoverlord.com/2011/08/31/git-on-your-web-server-a-security-reminder/</link><pubDate>Wed, 31 Aug 2011 22:53:21 +0000</pubDate><author>david@systemoverlord.com (David Tomaschik)</author><guid>https://systemoverlord.com/2011/08/31/git-on-your-web-server-a-security-reminder/</guid><description>&lt;p&gt;
	Earlier this month, I wrote about &lt;a href="https://systemoverlord.com/2011/08/04/managing-drupal-with-git"&gt;managing a Drupal site with git&lt;/a&gt;.  What I neglected to remember, of course, is this places a full copy of your git repository within your web server's document root.  This has the potential to expose any data in your git repository -- a malicious attacker could (depending on your configuration) clone the entire repository, thus exposing source code, configuration files, database dumps, and other sensitive data.&lt;/p&gt;</description></item><item><title>Managing Drupal with Git</title><link>https://systemoverlord.com/2011/08/04/managing-drupal-with-git/</link><pubDate>Thu, 04 Aug 2011 23:40:56 +0000</pubDate><author>david@systemoverlord.com (David Tomaschik)</author><guid>https://systemoverlord.com/2011/08/04/managing-drupal-with-git/</guid><description>&lt;p&gt;
	For a while now, I've been meaning to manage my Drupal site (and the modules and features on it) with git.  The release of Drupal 7.7 provided a perfect opportunity to make this transition.  I've now cloned the main Drupal.org git repository, added my features (as submodules) and added the modules I use (also as submodules).  I'm still getting used to working with git, and I wish there was a way to push parts of my configuration remotely, but I understand why you can't.&lt;/p&gt;</description></item><item><title>Automatically Creating Archives from Git Tags</title><link>https://systemoverlord.com/2011/07/16/automatically-creating-archives-from-git-tags/</link><pubDate>Sat, 16 Jul 2011 13:33:05 +0000</pubDate><author>david@systemoverlord.com (David Tomaschik)</author><guid>https://systemoverlord.com/2011/07/16/automatically-creating-archives-from-git-tags/</guid><description>&lt;p&gt;At work, we've been moving all of our development processes to git. As part of that, I've encouraged that alphas, betas, and releases be tagged in git -- it's important to know which versions are in use where. Additionally, my director wanted archives (zips/tars) of each of these versions to make it easier to install the releases, particularly for the members of our department who are not git-friendly. I realized that with git hooks and our use of gitolite, we could produce automated archives when tags with the words alpha/beta/release are pushed to the gitolite server. The script below is placed in the $GL_PACKAGE_HOOKS/common directory. It uses the name of the repository to decide if it should be archived (matches $ALLOW_ARCHIVE) and where the archive should be put (within $ARCHIVE_DIR).
&lt;/p&gt;</description></item></channel></rss>