First we need to get the git-subtree project:

~ git clone git@github.com:cordoval/git-subtree.git
~ 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
ec140481b9e7b7f18aa10516f5da6e43bbaea47a
~ git checkout ec140481b9e7b7f18aa10516f5da6e43bbaea47a
~ git checkout -b component/resourceWatcher
// from here on you can push to github.com

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 https://github.com/cordoval/ResourceWatcher.

Update: Thanks to @Stof for this link http://help.github.com/split-a-subpath-into-a-new-repo/
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

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 packagist.org 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": "https://github.com/cordoval/SmirikQuizBundle/zipball/master",
                    "type": "zip"
                },
                "autoload": {
                    "psr-0": { "Smirik\\QuizBundle": "" }
                },
                "target-dir": "Smirik/QuizBundle"
            }
        }
    ],
    "scripts": {
        "post-install-cmd": [
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets"
        ],
        "post-update-cmd": [
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets"
        ]
    },
    "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.

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?

Software evolves rapidly. Recently I realized I was not working with the latest developments on git.
I had the version below and I was getting an error:

~ git --version
git version 1.7.5.4
~ git branch --list
error: unknown option `list'

I tried to think in safer ways to upgrade to the latest git. I definitely had installed git through the packages that come with ubuntu repositories. So in order to play it safe, I needed to actually just get newer packages for git but from sources that were geared towards this:

~ sudo add-apt-repository ppa:git-core/ppa
~ git --version
git version 1.7.9.2

And the goodness started when I was able to run this –list command:

~ git branch --list
  binVendors
* master
  newBox
  seldaek
  temp

So today I tried to see if i can easily automate some of my decisions. I decided that vespolina sandbox was going in a way that it was not fitting my needs and the needs of someone like me that really wants to learn about how it works, how to do things, how to extend. I think a sandbox would be open to let you develop on top of it. It is not on the contrary a repo that you can just see through the window.

In order to support my ideas I had to fork vespolina sandbox and call it newbox. So from now on I will refer to newbox. It will have the same name still but I will just call it that way because I hope others will acknowledge that some decisions on the main repo were a mistake. This is open source, and I am allowed to think different. Now how to support, back up my points and thrive?

The question then is: Now how to support, back up my points and thrive? That is the question now we are heading to answer. In order to fork and decently maintain and include only the changes from other repos that we like and at the same time keep my changes intact we have to have a way to scrutinize, cherry pick commits, and keep track of what they are and have some sort of history of rejected changes… and why not accepted changes. Yes we complicate things when we fork a main repo in the old sense of the word fork. But we have to make a point. So here we go.

Background
I have tried to use git cola for cherry picking shas1 but it was a nightmare, so I knew it has to be done through the cli.

Analyze and Cherry Pick Flow

Analyze
So the first question we can ask is really: How to realize which commits are new on the upstream branch and which commits we lack on our local master or other branch. The command below `git cherry` does that and prefixes the new commits with + sign and the missing commits on upstream with a – sign. The other parts basically cut the 3 spaces before and leave the sha1 intact for us to reverse the order of the list of shas and feed that to a git show that will show us the patch code version of each commit.

~ git cherry master upstream/master | fgrep + | cut -c3- | tac | xargs git show

To give you an idea, the output looks like:

~ git cherry master upstream/master -v --abbrev=3
- 324b Updated composer.json, dropped some bundles to make V lighter
- a834 Updated dependencies & store configuration
- 16ea removed unwanted files
- aaa4 building with composer
- 2af8 removed kernel entries for missing bundles, added scripts to composer
- a2bb updated to use less files
- ddd1 deleted some unwanted code
- 4f8d create custom command to generate custom store
- beb2b fixed command options and set defaults, threw exception for TaxonomyName not found
+ 43dc Updated dependencies
+ fb58 update composer
+ 1562 add Application level ProductBundle and alphabetise
+ 866f update composer.lock

Cherry-pick
The complete command above will give us the code to look and identify which is the sha commit we would like to cherry pick. Yes it is still a tedious one to one task with each commit we cherry-pick. So given I want to say pick `fb58` from the above example then we do:

~ git cherry-pick fb58

If there are conflicts we solved them and commit and do our homework. And then again we run the analyze command on the first section and continue with the process having now a reduced list in which there is no commit `fb58`. At the end only the rejected changes are left. So on the early stages of a fork we have a reduced number of commits left out in the cherry difference. These commits and reasons for its rejections can be well documented in several ways. One could be doing:

~ git cherry master upstream/master -v | fgrep + | cut -c3- > rejectedCommits.txt

In turn we can track rejectedCommits.txt with git.

@SethRobertson which has written this and this and has pointed me to this rerere command is suggesting some interesting flow ideas like using git notes here to annotate the rejected commits.

The resolution of this would be how to filter the rejected and now annotated commits with a cli command and feed them to be explored with the git cherry command for the new acceptance cherry-pick cycle of new commits from upstream.

Until next series.
This is @cordoval and if you are hearing this you are the resistance.