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?

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

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.

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.

Tunnel The SSH Out of Git

While at a conference I have run through the embarrassment of not being able to `git push` over the ssh default port 22 through a local wifi.
The solution comes when one setups up a proxy or the repository server to take in connections over a different port. To enable server to take ssh connections over different port see this.
And then basically reduces to issue of tunneling in the case that there is a proxy server like here.
If there is no proxy then ssh directly, if there is a proxy then follow the procedure on the last link here.