Git Subtree Split: This is what Symfony2 does every night to set standalone Components!

First we need to get the git-subtree project:

~ git clone
~ sudo apt-get install asciidoc
~ sudo make install
~ sudo ./install // just to be sure :D

Now that our tool to do the job is installed it is time to filter all the commits and create our new repository, push to github and then add prehaps a composer to it that can in turn require the other dependency of Config Component.

~ git subtree split -P src/Symfony/Component/ResourceWatcher
~ git checkout ec140481b9e7b7f18aa10516f5da6e43bbaea47a
~ git checkout -b component/resourceWatcher
// from here on you can push to

Now our component is ready to be sourced from any project’s composer.json. Just remember to include also the Config component dependency.
You can find my personal repo at

Update: Thanks to @Stof for this link
They do it this way which makes a lot more sense 😀 and perhaps more git learning oriented:

[tekkub@tekBook: ~/tmp/github-gem master] $ git filter-branch --prune-empty --subdirectory-filter lib master

ResourceWatcher: The Component They Will Not Tell You About – Part I

Problem to solve

The problem that this component solves is when we have a system of files and folders that we want to watch for any
actions and react accordingly upon specific actions. Actions can be creation, edition, moving or removing. Upon each
action there could be a need to perform a specific re-action therefore the need for events and callbacks.


The way ResourceWatcher component is implemented to solve the problem is via main object resource watcher, a tracker
object, some resources objects to be tracked, events objects fired depending on what action happens on these resources,
generic event listeners already built-in to listen to the events fired when resources are acted upon, and state checkers
for these resources which will aid in discerning the state of a particular resource. Currently there are three types of
instances when we can react or types of events, namely: (when resource is) Created, Modified, or Deleted.

ResurceWatcher class can receive any custom tracker object that suits the developer, however the component comes with
two implementations of tracker ready to be used as sensitive defaults. In other words, if custom tracker is not provided
then the resource watcher will use an InotifyTracker or RecursiveIteratorTracker implementation. Once a tracker has been
specified and a watcher has been built with it then the next step is to determine what resources we want to track.


Example using ResourceWatcher with a custom tracker explicitly set, with folder `src` as resource and it will output on
console the name of the file being acted upon checking every microsecond within the 10000 first microseconds:

    use Symfony\Component\ResourceWatcher\ResourceWatcher;
    use Symfony\Component\ResourceWatcher\Tracker\InotifyTracker;
    use Symfony\Component\Config\Resource\DirectoryResource;
    $tracker = new InotifyTracker();
    $watcher = new ResourceWatcher($tracker);
    $resource = new DirectoryResource(realpath(__DIR__.'/../src'));
    $callBack = function ($event) {
                    $fileName = (string) $event->getResource();
                    echo $fileName;
    $watcher->track($resource, $callBack);
    $watcher->start(1, 10000);

Example using ResourceWatcher using default sensitive tracker, lame callback and single file as resource, checking every
microsecond for a time limit of 1 microsecond, and finally making sure it stops tracking resource right after.

    use Symfony\Component\ResourceWatcher\ResourceWatcher;
    use Symfony\Component\Config\Resource\FileResource;
    $watcher = new ResourceWatcher();
    $cb = function(){};
    $resource = new FileResource('demo.txt');
    $watcher->track($resource, $cb);
    $watcher->start(1, 1);

Today I have PR’ed the symfony-docs repo with documentation that is based on a experimental branch from @everzet here.

Thanks my forgiving Lord Jesus for this excitement of documenting this very interesting piece of code! I am so excited about working with this piece of code.

How to update your gist gem :D

This is how you update your gist gem:

// update your gem
~ gem update gist
// display the global configuration
~ git config --list
// the new change is that now you need your password exposed
~ git config --global github.password "your-github-password"

This is community pressure in action here –>

How to use Composer without Packagist like a Newbie

Say for instance you want to use a bundle from someone else, however that someone has not taken the time to update her repository with a composer.json neither has she taken the time to register her repository in site. You don’t have time to wait for a PR to be accepted and then waiting for the developer to register whenever. So you take the thing in your own hands and register it yourself on packagist within your own vendor namespace? Wrong!

Here is how it is done, this is indeed a real example:

    "name": "symfony/framework-standard-edition",
    "autoload": {
        "psr-0": { "": "src/" }
    "require": {
        "php": ">=5.3.2",
        "symfony/symfony": "2.1.*",
        "doctrine/orm": "2.2.0",
        "doctrine/doctrine-bundle": "dev-master",
        "twig/extensions": "dev-master",
        "symfony/assetic-bundle": "dev-master",
        "symfony/swiftmailer-bundle": "dev-master",
        "symfony/monolog-bundle": "dev-master",
        "sensio/distribution-bundle": "dev-master",
        "sensio/framework-extra-bundle": "dev-master",
        "sensio/generator-bundle": "dev-master",
        "jms/security-extra-bundle": "1.1.0",
        "jms/di-extra-bundle": "1.0.1",
        "cordoval/quizbundle": "1.0"
    "repositories": [
            "type": "package",
            "package": {
                "name": "cordoval/quizbundle",
                "version": "1.0",
                "dist": {
                    "url": "",
                    "type": "zip"
                "autoload": {
                    "psr-0": { "Smirik\\QuizBundle": "" }
                "target-dir": "Smirik/QuizBundle"
    "scripts": {
        "post-install-cmd": [
        "post-update-cmd": [
    "config": {
        "bin-dir": "bin"
    "extra": {
        "symfony-app-dir": "app",
        "symfony-web-dir": "web"

Now make sure you focus on the “cordoval/quizbundle” definition of the bundle. This is directing composer to install the dep from my fork of the bundle on github and not the original main repository one.

Note: When downloading from github or other url, if we instruct composer to do:

composer install --prefer-source

What it will do is to always download the source version of the releases so the source will have .git folder in it. If we don’t tell it and we instruct the version for the package to be different than dev-master then composer will always download the release distribution version which do not contain .git folder.

Invoke Sismo Only When Needed

There has been times when I want to commit but did not want to run a Sismo CI cycle. I have modified my own post-commit git hook with an if clause so that whenever RUN_SISMO variable is 1 then the post-commit hook gets executed. Whenever The RUN_SISMO environment variable is not defined or different than 1 then Sismo is not executed. So for instance:

// It will commit --amend without executing sismo
RUN_SISMO=0 git commit --amend
// It will commit --amend without executing sismo
RUN_SISMO=1 git commit --am "my new commit"

We can also permanently set the RUN_SISMO environment variable just by doing:

// to set sismo into running mode
export RUN_SISMO=1
// to prevent sismo running
export RUN_SISMO=0

There were other –no-verify flags but that flag only works for pre-commit hooks and not for post-commits. So we have to use environmental variables. The next thing we would like to automate so that we can copy our post-commit hook everywhere is the name of the project build. The build name is currently hard coded into the post-commit hook and has to be changed every time we copy it into a new project folder as it is not set as a global hook. An idea would be to have sismo.config.php which does have the build name to do some sort of environment setting so that the post-commit hook would know the name of the build. Any suggestions?