Which is just fine for smaller repositories but can take a long time on large repositories with a lot of large files in that directory.
The faster way is to manipulate only the index:

git filter-branch --index-filter 'git ls-files -- DIRECTORY | xargs git update-index --remove' --tag-name-filter cat --prune-empty -f -- --all;


• git ls-files will give you a list of files in the DIRECTORY
• git update-index will remove those files from the index
• And the tag filter is there to include tags
• –prune-empty tells filter-branch to ignore empty commits.

Done.

So my 2 cents:

What really makes people contribute:

1. A nice and encouraging community
2. Respect the work of others
3. Don’t take everything for granted

What doesn’t encourage people:

1. Continous rants about how to do things or not
2. Telling people what they do is totally wrong
3. Not contribute yourself

Open Source Projects are community driven. There is a place for discussion, but note that Open Source Communities are open, so people will come in and start ranting about things. If you are serious about a certain problem and want to solve it, contribute! If you want things to change, contribute! If you want to have your opinion heard, contribute! But do not try to squeeze argumentations in 140 characters and think everyone will follow you, just because it’s you.

Personally I’m getting tired of this, making me either not to contribute anymore (and you guys are stuck with SVN :)) or just ignore people.

In emacs use M-x slime-connect to connect to swank.

user> (use 'clojure.test)
nil
user> (use :reload 'geocommit.test.services) (run-test 'geocommit.test.services)
{:type :summary, :test 3, :pass 9, :fail 0, :error 0}

This blogpost gives you an example how to use geocommit and the geocommit.com services. I’ll show how to use geocommits in your Git or mercurial project. How to make github and bitbucket more beautiful with our Chrome and Firefox extensions and how to get a fancy map of your geocommits.

What is geocommit

First of all, geocommit is a text format to attach geolocation data to version control system commits. The geocommit website has detailed information about the geocommit format.
Second, geocommit is a service to store and analyse your geocommit data. We offer a set of tools and a webservice to make geocommit cool. The Git implementation git geo runs on Mac OS X and Linux. The Mercurial implementation hg-geo runs only under Linux. Mac OS support is under way.

Git & Geocommit

To start with geocommit, install git geo:

$ pip install geocommit

Go to a project directory and enable geocommit support:

$ cd myproject.git
$ git geo setup
geocommit setup
Installing geocommit hook in /home/dsp/awesomeproject/.git/hooks/post-rewrite
Installing geocommit hook in /home/dsp/awesomeproject/.git/hooks/post-merge
Installing geocommit hook in /home/dsp/awesomeproject/.git/hooks/post-commit

This will enable geocommit support in your project. If you commit something with git commit, git geo will try to get your current location and add a geocommit. If no WiFi connection is enabled, no geocommit will be created.

Check your geocommits:

$ git log --show-notes='geocommit'
commit 5a34e6ebc8cb5c2a394ca26505c1d375095161c4
Merge: 25cf72d 828af6e
Author: David Soria Parra 
Date:   Tue Jan 4 14:00:55 2011 +0100

    Merge branch 'master' of https://github.com/jezdez/geocommit

Notes (geocommit):
    geocommit (1.0)
    lat: 48.1211828
    long: 11.4853565
    hacc: 39.0
    src: nmg

Let’s push our geocommits to github:

$ git geo push

git geo push accepts the same options as git push. It pulls geocommits first, merges them and then pushes geocommits and the given branch to the remote repository.
That’s everything you need. Easy, isn’t it? So let’s see how to enable geocommits on Mercurial and then talk about the Chrome and Firefox extensions.

Mercurial & geocommit

You can add support for geocommits to Mercurial by installing the hg-geo extension. Clone the extension and enable it in your hgrc:

$ hg clone http://bitbucket.org/segv/hg-geo
$ echo "[extensions]\ngeo=/path/to/hg-geo/geo.py"
$ hg help geo

The extension will add an additional line to every commit that you do.

$ hg commit
$ hg log -v
changeset:   9:236a0f4c3d2e
tag:         tip
user:        David Soria Parra 
date:        Sun Jan 02 03:01:04 2011 +0100
files:       .hgtags
description:
Added tag v1.0.0 for changeset 3079e3ff3083

geocommit(1.0): lat 48.1211306, long 11.4853251, hacc 30.0, src nmg;

Now push your geocommits to bitbucket.

$ hg push

bitbucket.org and github.com

We can push geocommits easily now. But how to use them? We can install the Firefox or Chrome extension. This will display a map next to your commit!

Firefox
To install the geocommit extension for Firefox you need Greasemonkey. Greasemonkey is a well know and supported extension that enables user scripts to safely modify the displayed website.

Install Greasemonkey from userscripts.org. You can then browse bitbucket.org or github.com and see a map of your geocommit:

Chrome
On Chrome install the plugin from
chrome.google.com

Post Hook

We offer a post hook that you can use with github.com and bitbucket.org. Your commits will be tracked by gecommit.com and we will create a global and a project specific map as well as provide further analytics as soon as possible.

github.com
To install the hook go to th eadmin section of your repository and select Service Hooks.

Add http://hook.geocommit.com/api/github as a POST service hook.

on bitbucket.org
Go to the admin seciton of your repository and select Services

Add http://hook.geocommit.com/api/bitbucket as a POST service hook

Thats about it. Browse www.geocommit.com/full.html to checkout your commits on our map.

Questions?!
Enjoy!

Read the incoming changes and save them in a bundle file:

$ hg incoming --bundle incoming.bundle http://selenic.com/hg

Now you can disconnect and review them offline.

$ hg -R incoming.bundle log --no-merges -p -- hgext/bookmarks.py
(log pops up)

The -R incoming.bundle option tells Mercurial to use the bundle as an overlay for the current repository. The –no-merges option tells Mercurial to not display merges (which I usually use for reviewing patches) and the -p option is there to display the applied patches in the output. I use – hgext/bookmarks.py to display only changesets related to the bookmark extension.

Everything’s good, let’s pull it:

$ hg pull incoming.bundle
pulling from incoming.bundle
searching for changes
adding changesets
adding manifests
adding file changes
added 113 changesets with 281 changes to 204 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)

This is a series of blogposts that consists of three parts:

(1) Part I: History of Bookmarks
(2) Part II: Daily Bookmarking
(3) Part III: Pushable Bookmarks

UPDATE I’m aware that people wait for Part II. Let me see if I can write about it this weekend…in the meantime, click the flattr button :)

I stumbled over Mercurial in August 2007. Back then I had already
used Git for 6 months, but wanted
to try out different distributed version control systems (DVCS).
I soon began to like Mercurial’s approach because of its simple and
intuitive interface and its clean codebase. While playing around
with Mercurial for a few weeks I was content with its concepts.
There was one feature missing
that I really like in Git: git-like branches.

Unlike in Mercurial or in any other version control system, branches in
Git are simply lightweight markers pointing to a commit. Every ancestor of
the commit is considered part of the branch. Back then, this sounded odd to me. Later I realized it was a really good tool to create small local branches. You can create a small branch
for a feature, merge it into your mainline, and remove the branch
without anyone knowing you ever had a branch called
‘stupid-little-feature‘. To make a long story short: It’s a good
idea to have a similar concept in Mercurial, but none existed back in 2008.

In June 2008 I started developing Mercurial References providing lightweight branches similar to those available in Git. Although the initial work was appreciated by the community, it was rejected
in favor of a concept more natural to Mercurial. Matt Mackall, the author of
Mercurial proposed Mercurial Bookmarks.

Bookmarks

The concept of bookmarks is easy:
You can bookmark a commit with a unique name. So it’s similar to
a tag, with one exception, a bookmark advanced when you commit.
(Like real bookmarks when you go to the next page).

I wrote an initial version of Mercurial Bookmarks in August, that
was finally accepted in October. This improved git like workflows
in Mercurial but still the implementation was far away from what I
wanted. By adding the notion of a so called “current bookmark”, it
got better. Still bookmarks had one major drawback in comparison
to git style branches. They were local only. There was no way to
push or pull bookmarks.

Pushable bookmarks

This was the status for the past two years. I tried to make bookmarks
pushable during this time. A proposal by me how extensions in general
can exchange arbitrary information over the wire was rejected in
early 2009 because it was too unrestrictive for the protocol. A new
concept, so called ‘pushkey concept’ was developed in 2009. This
was discussed and accepted during the Mercurial Sprint in Paris,
January 2010.

Matt Mackall, who now gets sponsored to work on Mercurial,
worked on the initial implementationof pushkey and
pushable bookmarks. And finally after two years of ongoing complains
by people about local-only bookmarks, Mercurial 1.6 will have
pushable bookmarks and introduces a great new concept to exchange
metadata information between repositories.

The next blogpost will show you how to use bookmarks.

To use the php-trunk portsfile. Just extract the tarball into a directory and…

$ tar xzvf php-trunk-port.tar.gz
$ cd php-trunk-port
$ echo "file://`pwd`" > /opt/local/etc/macports/sources.conf
$ echo "file://`pwd`" >> /opt/local/etc/macports/sources.conf
$ port install php-trunk


And the best thing about the port: It compiles PHP with dtrace support :).

Please note the Portfile is very simple and is not tested with the additional modules provided by macports. So use it at your own risk and enhance it.

DOWNLOAD

UPDATE: as philip noted, it should be >> instead of >.

To compile PHP with DTrace, on Solaris or Mac OS do:

  $ svn co http://svn.php.net/repository/php/php-src/trunk php
  $ cd php
  $ ./buildconf --force
  $ ./configure --enable-dtrace
  $ make

To check if your PHP has DTraces probes enabled, you can check the phpinfo() using

 $ php -i | grep DTrace

or use DTrace directly>

 $ sudo dtrace -ln 'php*:::' -c 'php -m'

88836    php4614               php               dtrace_compile_file compile-file-entry
88837    php4614               php               dtrace_compile_file compile-file-return
88838    php4614               php                        zend_error error
88839    php4614               php  ZEND_CATCH_SPEC_CONST_CV_HANDLER exception-caught
88840    php4614               php     zend_throw_exception_internal exception-thrown
88841    php4614               php           dtrace_execute_internal execute-entry
88842    php4614               php                    dtrace_execute execute-entry
88843    php4614               php           dtrace_execute_internal execute-return
88844    php4614               php                    dtrace_execute execute-return
88845    php4614               php                    dtrace_execute function-entry
88846    php4614               php                    dtrace_execute function-return
88847    php4614               php              php_request_shutdown request-shutdown
88848    php4614               php               php_request_startup request-startup

Have fun with DTrace in PHP.

A few examples will follow in the next days.