Updating Git to the Latest On Ubuntu

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
~ 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

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

~ git branch --list
* master

The Git Series II: The one which they don’t want you to see

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.

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

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

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.

Hacking Day March 2012 + Lunch Time!

We had a great time from 9am to 4pm today hacking code thanks to @lennon and @jamdiaz from UPC. Had on skype @nacho from Spain who encouraged people to do their best at the start of the day and we had @ocramius from Germany who gave us a hand all the way to the end with code reviews over github. We took a short break to eat before we came back to pound the stuff again. I am thankful the Lord Jesus Christ for this grace for allowing me to share and include people that are learning php and good methodologies in designing and developing. I pray this effort would yield fruit in the end. Encouragements in all good things.