Harsh J

When you’re heading out to give back something to the world by cloning out repositories of code hosted by beautiful git servers around the world and making edits to it in order to submit a clean patch, you might wonder sometimes: Why on earth does cloning repositories take SO much time?

Well the answer is that a proper clone will fetch all changes that were ever made in the project’s history, and you are receiving all of that into your clone.

While this is okay with new projects you’re butting into, it might take a ridiculous amount of time when you’re cloning something that’s been for a long time and has ALL its history intact (for reasons best known by their true developers )

If your contribution is going to be a simple quick-patch-and-go-smile (which is perfectly fine, if you ask me – all form of contributions are great!) you should use this lesser known option of git-clone called depth.

Use a clone command as so, for example:

# Use the -depth=n option with a small number, to fetch only those many changes
# counting backwards from HEAD.
git clone git://github.com/QwertyManiac/avroutils.git --depth=1

This will fetch only the HEAD of the repository as part of the objects download. Your download size and time would be greatly reduced thus.

Do note, however, that you may not be able to clone from this copy, nor pull or push from/to it. These form of clones are called ‘shallow clones’. Read more upon it here if you may want to.

Officially an Android OS owner now. Celebratory image follows:

Samsung Galaxy S

Read the rest of this entry »

It was one of those days where I go all ‘what the hell is going on?’ and sit down to fix a problem I’m facing with my Linux desktop and eventually begin swimming with sharks an hour later.

When I recently used Windows 7 on my machine to play StarCraft II, I noticed that I was getting my updates from them at about 512 kbps. I was confused; for months I’ve ranted to many that among them all BSNL (ISP) users out there I was the only one still having my speeds undoubled (as the ISP had claimed to have done a few months ago). On Linux, I never see my downloads (wget, rtorrent, whatever…) go beyond 256 kbps. This was very strange – that downloading a file on Windows gave me a higher speed than downloading the same file after booting into Linux.

In times of such crisis, I usually pour out concerns onto a channel where Kalpik usually resides. He has this weird knack of directly, and more likely indirectly point me to my solution. And he did it again.

Apparently, a few months ago, in some desperate need of better browsing while running bittorrent downloads/uploads I looked up some ‘better’ QoS serving script at LARTC and had applied it down into the roots of my ArchLinux installation manually. I had completely forgotten about that!

Now this script has a DOWNLINK amount one usually sets in it to get it to work properly. And I’d set mine to what was available to me back then – 256 kbit per second. And since then, I’d always been seeing a steady stream of 30-32 kBps in all my downloads on Linux (it capping the rest out?), wondering when I’d get that double offer my ISP had given to all of its unlimited-plan users.

I’m still hunting for that file and the caller for the same script; but in the meantime (read: grep time) I’ve removed linux-atm and iproute2 packages of ArchLinux which were needed to facilitate the script (These came back as a flash to me) and (thanks to Kalpik again for hinting “What tc?”) I’m seeing the same download rates on Linux as on Windows. No funny limiting is occurring in the middle anymore. Phew.