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
Contents
Intro to Git[edit | edit source]
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 might want to migrate from Subversion to Git
Tools[edit | edit source]
Documentation[edit | edit source]
- http://wildlyinaccurate.com/a-hackers-guide-to-git Helpful intro because it doesn't pretend that Git is just like Subversion
- 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://utsl.gen.nz/talks/git-svn/intro.html This intro for git-svn (a combination of git + svn) actually provides a lot of information and especially gives perspective if you've tried to use svk.
- http://git.or.cz/course/svn.html
- 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
Git and Subversion[edit | edit source]
- http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion
- http://viget.com/extend/effectively-using-git-with-subversion
- http://trac.parrot.org/parrot/wiki/git-svn-tutorial
- http://flavio.castelli.name/2007/09/04/howto_use_git_with_svn/
Now what?[edit | edit source]
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[2]), 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,[3] Dries, et al.[4]) 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 [5] (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.[edit | edit source]
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[edit | edit source]
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
References[edit | edit source]
Rant[edit | edit source]
- 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. [1]
So, according to the official Subversion manual, the right way to track source code that you build on, you should
- download an export (they don't even consider that your vendor should be and IS using a VCS)
- add stuff that they added
- launch external tools to find out if there were deletions
- or just ignore deletions (tell me why we're using source code managment tools?)
- 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 [2], 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
References[edit source]
- ↑ 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