Mallik’s visit to Mumbai would’ve been pointless without a visit to the newly crowned UNESCO Heritage Site, Western Ghats, our beloved Sahyadaris.
The destination this time around was a simple one, Sondai fort Trek. Close to the Morbe Lake Dam, near Karjat. This place had its own little lake dam, the Vaverle Lake Dam.
The participants were Mallik’s rock climbing group buddies, Ritz, Farzheen, Sneha, Aditya, Meenaz. Me and Vj were just the climbing pals, the rocks seemed to shun us everytime we tried to overcome them.
Mallik stayed overnite with me, and we picked up Vj early morning from Bandra Station. “Picked up”, yes, this was the 5-star trek of ours, a direct car commute to the base of the village. Others joined us at Kalanagar junction and we headed straight to Dutta Snacks, at the Panvel junction. A lazy lavish hour spent there having Batata Vada, chai, etc. My first trek with Farzheen, and the pit-stop at Dutta snacks made perfect sense.
Another 15 minutes, and we were at the chowk junction. The rains were lashing hard, we thought that it was the first time this region including Mumbai was getting the heavy downpour of the season. At Sion junction, it was just 6.30am and it was already flooding. A left from Chowk/Karjat junction and few more minutes in the now decaying road conditions took us to Borgaon junction where we took a left and then wandered towards the Vaverle village, all in a car!
The country side was green, with every single green hue visible with the unsaturated grays of the hovering clouds simply dousing over the hills. The Sondai fort-hill was hidden behind the fluffy puffs. A small climb on top of what seemed like a wall opened up gasping landscape of a lake being nurtured by small hillocks on each side.
The actual trek itself was a small 1 hr climb, mostly including trail walks. At the top we had some more food, thanks to Vj and Mallik’s bags which contained loads of tasty food and lots of Katchi beer ( छाछ ). At the base, the lake awaited us, I was the first to get into the water body, which welcomed me with warm water. The sight was simply irresistible for others, and soon everybody followed.
Almost half-hour into the lake, and still all hesitated to move out. Mallik had already left. It was Mallik’s call for Maggi that put everybody in dilemma. A hot maggi on a rainy afternoon after a dip in the lake was something that nobody wanted to miss. We had maggi and other restover food in a small hut where another group was playing with an air gun and trying to determine whose pellet went longest in the pool! No wonder we miss out on so many of those shooting medals.
Back at the car, we got into our dry wear, with RD Burman’s songs blasting through. On our way back we halted at a restaurant in Nerul for snacks and then back to our concrete and mortar.
[CHORUS]
C G
Zindagi ...kaisi hai paheli, haaye
F C
Kabhi to hansaaye kabhi ye rulaaye
x2
C F
Kabhi dekho man nahi jaage
C
peechhe peechhe sapno ke bhaage
x2
C G
Ek din sapno ka raahi
F C
chalaa jaaye sapno ke aage kaha
[CHORUS]
Zindagi...
C F
Jinhone sajaaye yaha mele
C
sukh-dukh sang-sang jhele
x2
C G
Wahi chunkar khaamoshi
F C
yu chali jaaye akele kaha
[CHORUS]
Zindagi...
Strumming Pattern
Down Down Up … Up
In “chalaa jaaye sapno ke aage kaha”, the C chord has to be struck just once – down stroke, Same for “yu chali jaaye akele kaha”. Alternatively you can ignore strumming after G chord and just strum F chord once followed by last down stroke of C chord giving the “talk” feel.
Many times in development, you pull in remote branches and over a period of time they become stale and get deleted on the server. But your local repository still keeps a reference of those. You need to clean stale / deleted remote branches on your local system
A simple command git remote prune helps.
Check which branches are dpresent on local and getting tracked
The option -n is a dry-run option, showing which branches can be deleted/pruned on your local – as in this case test-branch. So we can go ahead and actually prune/cleanup
The remote branch origin/test-branch has been knocked off locally, but the local branch test-branch remains. If wanted, we can clean-up the local as well
If you’re reading this, you’re an avid user of git, have made tons of commits and now you’re trying to find..
where the hell did the bug get introduced ?
git-bisect is a perfect tool to find that. To explain this awesome tool, I’ve created a small demo-repository which has only one file text.txt. In this file, I’ve incrementally added a, b, c, d and so on in each commit.
This is how my file text.txt looks like
[rutu@ruturaj-vartak git-bisect-demo]$ cat text.txt
a
z
c
d
e
f
g
h
i
j
k
l
m
n
My git graph/log looks as below
If you are wondering what is “git g” its just an alias, following is my ~/.gitconfig
[rutu@ruturaj-vartak git-bisect-demo]$ cat ~/.gitconfig
[alias]
ci = commit
st = status
di = diff
co = checkout
k = !gitk --all
g = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --all
d = difftool
[color]
ui = true
[user]
name = Ruturaj K. Vartak
email = ruturaj@localhost
[diff]
tool = vimdiff
To simulate a bug, somewhere in my code, I’ve replaced b with z. Now the with the current state of my code, I’ve got to find where and who introduced z in my code ?. Lets begin
git-bisect uses BST style division and search mechanism. So lets start.
Start with a command,
$ git bisect start
Now its necessary to tell git, that where was the code good and bad. Obviously my code was good at revision b162893 and the HEAD or 20bacecis now bad. So ..
$ git bisect good b162893
$ git bisect bad 20bacec
Now if you check the git graph…
Notice how git has divided this history into 2 parts, and the HEAD now points to the partitioning commit fa70446.
We can now cat the file and see if the bug was introduced.
[rutu@ruturaj-vartak git-bisect-demo]$ cat text.txt
a
b
c
d
e
f
g
h
As you see, the bug still has not been introduced, so lets tell git that this commit is GOOD
$ git bisect good
Now lets look how the graph looks
The head is now d126a8f, the half between 20bacec and fa70446 and lets cat our file, text.txt
[rutu@ruturaj-vartak git-bisect-demo]$ cat text.txt
a
z
c
d
e
f
g
h
i
j
k
Wohoo ! our bug is existing here, but we don’t know if it was added in b38e6d7, df4f3bc or the HEAD – d126a8f
So we now tell git, that this is BAD commit $ git bisect bad
Now lets look at our graph,
It has made another division, HEAD now pointing to df4f3bc
Lets see if this HEAD is GOOD or BAD,
[rutu@ruturaj-vartak git-bisect-demo]$ cat text.txt
a
b
c
d
e
f
g
h
i
j
Hey !!! The bug is non-existent over here. Lets tell git the good news
$ git bisect good
And this is what it returns us back
[rutu@ruturaj-vartak git-bisect-demo]$ git bisect good
d126a8fbd75cbf5e015228f0411d205745a77e05 is the first bad commit
commit d126a8fbd75cbf5e015228f0411d205745a77e05
Author: Ruturaj K. Vartak
Date: Sat Jul 7 12:32:04 2012 +0530
added k
:100644 100644 92dfa216416a1ac944633ab674568f8bae139d95 261ccd63acaba8ae42219a40579a9acec61f05d0 M text.txt
Since there were no commits between our last found BAD commit – d126a8f and our current HEAD – df4f3bc, git has determined the bug was introduced in d126a8f. It throws a complete info stack of what it has for that commit.
This is how our final graph looks like
Note: there is nothing left to check between d126a8f(BAD) and df4f3bc(GOOD)
The last thing to do, is reset everything with git bisect reset
Which leaves a clean state
[rutu@ruturaj-vartak git-bisect-demo]$ git bisect reset
Previous HEAD position was df4f3bc... added j
Switched to branch 'master'
[rutu@ruturaj-vartak git-bisect-demo]$ git g
* 20bacec - (HEAD, master) added n (3 hours ago)
* c7edac3 - added m (3 hours ago)
* 83a34bc - added l (3 hours ago)
* d126a8f - added k (3 hours ago)
* df4f3bc - added j (3 hours ago)
* b38e6d7 - added i (3 hours ago)
* fa70446 - added h (3 hours ago)
* e4efb05 - added g (3 hours ago)
* 8fe6f2a - added f (3 hours ago)
* 96381ba - added e (3 hours ago)
* a07ce18 - added d (3 hours ago)
* 0b824e0 - added c (3 hours ago)
* b162893 - added b (3 hours ago)
* 7a60f8d - added a (3 hours ago)
Automating git bisect
Even though the above method looks easy, it could be painful if you’re going through 100s of commits. git has an automated way as well, using the git bisect run. Lets look how we can search our above code for bugs using the automated way
For git bisect run cmd, It needs an argument of a command that’ll do the search of bug in the script and return exit code 0 for GOOD or 1 for BAD.
Lets create a simple bug-finder.sh script that will grep for b, if grep finds, it’ll give exit status as 0, or else 1. We’ll capture the exit status of grep and throw as exit status of our script. We’ll place our bug-finder.sh in root folder of our repo.
Here is the script, Make sure you chmod +x bug-finder.sh
[rutu@ruturaj-vartak git-bisect-demo]$ cat bug-finder.sh
#!/bin/bash
grep "b" text.txt
exitCode=$?
if [ $exitCode -eq 0 ]; then
exit 0;
else
exit 1;
fi
Lets begin, steps stay the same…
$ git bisect start
$ git bisect good b162893
$ git bisect bad 20bacec
Now, the magic – $ git bisect run ./bug-finder.sh
The output is as follows – git successfully finding the bug
[rutu@ruturaj-vartak git-bisect-demo]$ git bisect run ./bug-finder.sh
running ./bug-finder.sh
b
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[d126a8fbd75cbf5e015228f0411d205745a77e05] added k
running ./bug-finder.sh
Bisecting: 0 revisions left to test after this (roughly 1 step)
[df4f3bc1e079bc75afd922726c719e16d1e4efdf] added j
running ./bug-finder.sh
b
d126a8fbd75cbf5e015228f0411d205745a77e05 is the first bad commit
commit d126a8fbd75cbf5e015228f0411d205745a77e05
Author: Ruturaj K. Vartak
Date: Sat Jul 7 12:32:04 2012 +0530
added k
:100644 100644 92dfa216416a1ac944633ab674568f8bae139d95 261ccd63acaba8ae42219a40579a9acec61f05d0 M text.txt
bisect run success
There it is, simply and cool. Ofcourse in this case a lot depends how and what you’ve coded in ur bug-finder.sh. A bug in this script will just fool git.
Russia was knocked off the Euro 2012 by Greece by their achievement of scoring more goals than Greece.
Their sin – they lost to Greece. I wonder if the strategy to give heads-up to a team only ’cause their one-on-one record is better than a goal difference is a good one!
So when it ended, stats were ..
Russia
Greece
Points
4
4
Goals For
5
3
Goals Against
3
3
Goal Diff
2
0
Yellow Cards
6
9
Red Cards
0
1
I wonder why other statistics too were ignored? Is head-to-head a better criteria to move a team up?
At the end of the touching episode on female foeticide, Swanand Kirkire with his self composed song O re Chiraiya sung a heart melting song with Ram Sampath.
Key – G
Those who want a cleaner chord, could use C instead of C9 – C9 is just easier to play, but Cmajor sounds better.
O Ri Chiraiya, Nanhi si chidiya
G C9 G C9 G
Angana mein phir aaja re
D G
O Ri Chiraiya, Nanhi si chidiya
G C9 G C9 G
Angana mein phir aaja re
D G
Andhiyara.. hai ghana
Em G
Aur lahu se sana
C D
Kirno ke tinke, ambar se chunn ke
G C9 G C9 G
Angana mein phir aaja re
D G
Humne tujhpe hazaaro sitham hai kiye
G C9 D G
Humne tujhpe jahaa bhar ke zulm kiye
G C9 D G
Humne socha nahi, Tu jo udh jaayegi
G C D G
Ye zameen tere bin sooni reh jaayegi
G C D G
Kiske dum pe sajega mera angana
G C9 D C D
O Ri Chiraiya, Meri chiraiya
G C9 G C9 G
Angana mein phir aaja re
D G
Tere pankho mein saare sitare jadhu
G C9 D G
Teri chunar thanak setha satrangi bhunu
G C9 D G
Tere kaajal mein main, kaali raina bharu
G C D G
Teri mehandi mein main, kachi dhoopa malu
G C D G
Tere naino sajaa doon naya sapna
G D C D
O Ri Chiraiya, Meri chiraiya
G C9 G C9 G
Angana mein phir aaja re
D G
O Ri Chiraiya, Nanhi si chidiya
G C9 G C9 G
Angana mein phir aaja re
D G
O Ri Chiraiya
G C9