Git

The Git system (http://git-scm.com/) was originally developed by Linus Torvalds as a distributed version control system to replace BitKeeper for the Linux Kernel project

Intro to Git

The IIC has a new git repository hosting service.
You can browse our git repositories at http://svn.iic.harvard.edu/gitweb/

Why do we have git? Because Git is better than X Now that we have the "My DVCS is better than your DVCS" argument out of the way, you can actually get some valuable insights from that website if you are interested in comparing Git with Mercurial, Bazaar, Subversion or Perforce. If I had to single out one primary advantage of Git, it would be that it actually features branching and merging.

Repo visibility is completely customizable, as are individual permissions to write to repos. I've installed a system called gitosis to handle the privileges through a special git repository. It uses Public Key cryptography rather than granting SSH accounts to everyone. This makes it really easy to do your work securely without even needing a password. For the curious, the actual mechanics of gitosis are detailed at scie.nti.st

You can actually host your own private repository on any server that you have access to. To collaborate with your peers, export a bare repo and use SSH keys. more

To host a public repo, go to http://github.com

Tools

• http://git-scm.com/tools
• http://github.com/guides/using-the-egit-eclipse-plugin-with-github

Documentation

• http://www.gitcasts.com GitCasts
• http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday Git in 20 commands
• http://git-scm.com/course/svn.html Git crash course for SVN users
• http://software.complete.org/software/wiki/site/GitGuide Git Guide (short) at Software Complete.org
• http://book.git-scm.com/index.html
• http://git-scm.com/documentation
• http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
• http://www.kernel.org/pub/software/scm/git/docs/git-config.html
• http://github.com/guides/providing-your-ssh-key

Now what?

I got into Git to make managing Drupal projects possible. Now that we have a distributed VCS, we can actually collaborate in multiple ways (more than just a centralized model), and we can work offline . We can easily branch and merge. We can pull in updates from the Drupal core maintainers. We can pull in updates from the Drupal community (module maintainers). We can track our own custom modules - especially if they are developed by more than one person. We can branch, tag and deploy these combined sources to multiple instances (dev, staging, production) across multiple instances of Drupal (e.g. client projects that should share the exact same codebase) and have complete clarity on where each project stands regarding patches and security fixes or updates. There have been several attempts in the Drupal community (credit to Moshe, Ben, Dries, et al.) to get this all working over the past year or so and I think we're finally seeing the tide turn in our favor. Drupal may actually start to be "easy" to maintain and deploy. Actually, the whole point is to BE up-to-date on all our projects. This only happens when it is feasible. Git makes it feasible.

• http://versioncontrolblog.com/2007/08/02/upgrading-drupal-52-with-git/
• http://www.aidanf.net/node/133
• http://github.com/mikl/drupal/tree/master

I pulled down the whole clone (which is only 26MB in size) of mikl's public history of Drupal in a few minutes.

With Git is even possible to manage projects which are composites of multiple sources (Ever tried that with Subversion's 'externals'? -- Don't bother to try it with Subversion because it just doesn't work! Not only are externals feature poor, you'll still end up wanting to merge even more than before. And as we know, merging is not a feature in Subversion.)

Comparisons of Branches, sources etc.

When comparing large trees of files, you need a good set of tools to be able to filter out noise. Normally KDiff3 is very good at this. However, KDiff3 is not available yet as a package for Ubuntu. If you compile it from source, I still found that the most important feature -- the preprocessor -- would not work if more than one command were piped together.

Specifically, I couldn't use this preprocessor setting which worked great for me in the past: sed "s/\$\(Id\|Revision\|Author\|Log\|Header\|Date\).*\$/\$\1\$/" | sed "s#/\* vim: set.*#/* vim: set ... */#" | sed "s/^.*opyright.*$/Copyright Greg Rundlett :-)/"

Without the benefit of a good preprocessor, KDiff would falsely tell me that there were 1,523 files which differed between DRUPAL-6-9 and DRUPAL-6-10

Kompare seemed hard to configure, and Meld didn't apply the pre-processor to directory compares. So, I used the command-line version of diff:
greg@greg-linux:~/work/git/drupal$ diff -r --exclude=.git --exclude=.svn --brief --ignore-matching-lines="$Id" . /var/www/drupal/

Only in /var/www/drupal/: favicon.ico
Only in /var/www/drupal/sites/all: modules
Only in /var/www/drupal/sites/all: themes
Only in /var/www/drupal/sites: dev.example.org
Only in /var/www/drupal/sites: example.org
Only in /var/www/drupal/sites: localhost
Only in /var/www/drupal/sites: prod.example.org
Only in /var/www/drupal/sites: www.example.org

How it was done

Generally following the series of instructions at http://vafer.org/blog/20080115011413 I installed Git-core, gitweb and gitosis on the host

# install git, the git-svn tool and the viewvc equivalent
apt-get install git-core git-svn gitweb

# run the git-daemon - a really simple server for git repositories
sudo -u git git-daemon --reuseaddr --verbose --base-path=/home/git/repositories/ --detach

# create a service that starts when the machine starts
cat > /etc/init.d/git-daemon << EOF
#!/bin/sh

test -f /usr/bin/git-daemon || exit 0

. /lib/lsb/init-functions

GITDAEMON_OPTIONS="--reuseaddr --verbose --base-path=/home/git/repositories/ --detach"

case "$1" in
start)  log_daemon_msg "Starting git-daemon"

start-stop-daemon --start -c git:git --quiet --background \
--exec /usr/bin/git-daemon -- ${GITDAEMON_OPTIONS}

log_end_msg $?
;;
stop)   log_daemon_msg "Stopping git-daemon"

start-stop-daemon --stop --quiet --name git-daemon

log_end_msg $?
;;
*)      log_action_msg "Usage: /etc/init.d/git-daemon {start|stop}"
exit 2
;;
esac
exit 0
EOF

# and add it to the various run-levels
update-rc.d git-daemon defaults

# setup the configuration of the gitweb repository browser
vi /etc/gitweb.conf

# Add cgi capabilities to our "Version Control" host
vi /etc/apache2/sites-available/git

# check the syntax of our apache configuration
apache2ctl configtest

# oops, the mod_rewrite isn't enabled
a2enmod rewrite

# check syntax and errors again
apache2ctl configtest

# restart apache
/etc/init.d/apache2 restart

# see what may have been added to the web docroot
ls /var/www/

# check to see that gitweb is installed
# and see what files it installs since they aren't in /var/www
dpkg --status gitweb
dpkg --listfiles gitweb

# create a symbolic link between the gitweb software and the repository root where we'll be viewing it.
ln -s /usr/share/gitweb /home/git/

# see what we have so far
ls /home/git/

# setup our gitweb configuration
vi /etc/gitweb.conf

# check if gitosis is packaged for ubuntu
apt-cache search gitosis
# and install it
apt-get install gitosis

Rant

quote 

After replacing the 1.0 code with 1.1 code, svn status will show files with local modifications as well as, perhaps, some unversioned files. If we did what we were supposed to do, the unversioned files are only those new files introduced in the 1.1 release of libcomplex--we run svn add on those to get them under version control. If the 1.1 code no longer has certain files that were in the 1.0 tree, it may be hard to notice them; you'd have to compare the two trees with some external tool and then svn delete any files present in 1.0 but not in 1.1. (Although it might also be just fine to let these same files live on in unused obscurity!) Finally, once our current working copy contains only the libcomplex 1.1 code, we commit the changes we made to get it looking that way.

So, according to the official Subversion manual, the right way to track source code that you build on, you should

1. download an export (they don't even consider that your vendor should be and IS using a VCS)
2. add stuff that they added
3. launch external tools to find out if there were deletions
4. or just ignore deletions (tell me why we're using source code managment tools?)
5. commit those changes

They admit that this is not exactly what you would like: "...things can quickly degrade into a situation where we have to manually re-create our customizations in the new version."

The official manual continues: "Vendor drops that contain more than a few deletes, additions, and moves complicate the process of upgrading to each successive version of the third-party data. So Subversion supplies the svn_load_dirs.pl script to assist with this process."

Except that svn_load_dirs.pl does not come with Subversion , and even if it did, it has limited or zero capabilities to handle and TRACK the status, history, and provenance of your source code. In any situation where a conflict arises, svn_load_dirs.pl will ask YOU to figure it out -- without any supporting details. Despite what the quote from the manual implies, the actual README with svn_load_dirs.pl says that it should NOT be used with sources that come from another VCS... those imports should be scripted ala cvs2svn etc.

I don't recommend looking at these, you'll just learn how NOT to do things. But here are examples of others who have needlessly fought with Subversion to manage their Drupal sites and source code

• http://minimalmedia.com/en/blog/dave/upgrading-drupal-core-with-vendor-branches-and-svnloaddirs-almost-perfect
• http://www.transmachina.com/en/drupal-subversion-repository
• http://www.davidgrant.ca/maintaining_vendor_sources_with_subversion
• http://www.burtonini.com/blog/computers/svn-vendor-2005-05-04-13-55

http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html

svn_load_dirs.pl had licensing questions and was removed from the project. Now I guess it's back, in a contrib section, not in a default install. Anyway, a newer, better set of options exist named collectively vcs-load-dirs

Version Control System