Truly grok, love and take pride in your repo’s commit graph.

To achieve this, these are some of the key points I follow.

Understanding the tree

Decent graph visibility

To truly understand DSCMs, you have to completely grok what’s happening on you repo in terms of commits, yours or otherwise. I find a decent graphical view goes a log way. And we have a very good one built in.

git log --graph --oneline --decorate --all

Try it!

If you really want to see all nodes, even those not reachable by a branch, try:

git log --graph --oneline --decorate --all $(git reflog | awk '{print $1}')

Have a sane branching model

Begin with git-flow’s model, but have git-workflow manpage in mind. Try it out. If it hurts, stop, think and, only then, act.

Building the tree

Learn to use the index

The index, or cache, or staging area (git should get its names strait) is a place where you put the hunks that should be in the next commit. Yes, hunks, not files. You can have a really fine grained control over what goes into the index with git add --patch. Selective removal of the index? git reset -p. Selectively throw out stuff not indexed? git checkout -p.

Make your commits laser focused

You should commit early and commit often. They should do one thing and do it right, on the right place in the commit graph. Don’t be afraid of having a commit with an one line diff and a commit message of “Whitespace.”.

This will make your history more browsable and understandable for other people. Your reviewers will buy you more drinks and you’ll thank yourself on the next time you have some serious merge/rebase conflicts.

Too many commits? Wish you could roll some of them into each other? Or maybe just re-order them? Use git rebase --interactive.

Forgot to include something in your last commit? Use git commit --amend.

Remember that public history must be immutable, atomic, and easy to follow. However, before you publish your commit, your private history is your own. It’s malleable, disposable and nobody’s business but your own!

Switch tasks fast

Is there something cramping you style you but you already have changes on you working copy? Use git stash, then go all out on your annoyance. When your done, checkout the right branch, and git stash pop.

Just remember that git stash won’t keep the untracked files. Add them to the index if you want to keep them.

Know when to merge or rebase

Merges should be meaningful. They convey a very strong message to others that says “I merged these two lines of thinking and made them compatible”. If you’re not merging lines of thinking, you shouldn’t be doing a merge. You should probably rebase.

Rebasing is the act of recreating a set of commits on top of a new node. If it helps you, think of it as “transplanting commits to a new place in the graph”.

Caveat: Pull tries to be your friend, but it’s just too eager to please

Don’t use git pull.

It’s meant to be a tool for syncing with upstream. It’s just a git fetch followed by a gratuitous git merge. Merges should be thought out. Fetches should not.

Handling upstream changes by hand can be laborious, though. So, use git pull --rebase. It’ll use rebase instead of merging your local history which will result in not having stupid auto-micro-merges.

To give your clone some rebase love, just do:

git config branch.autosetuprebase always
git b | cut -c3- | xargs -I= echo git config branch.=.rebase true

Honor public history

Don’t rebase public commits.

When you rebase, you’re creating new nodes and “forgetting” about the old ones. In your local clone, at least. In everybody else’s, the nodes are still there and they won’t be able to make sense of a bunch of duplicated nodes (not right away, at least). And they’ll have to do some (serious) commit gardening to put things back where they should be. That will be a lot of work, I can guaranty you.

So, in order to keep thing clean for everyone, don’t change stuff you’ve already published.

However, while your commits are not yet published, muck around at will! The aim is to provide a good new addition to the repo’s public history.

No rules beat practicality

These are just a set of guidelines. They’re meant to keep things clean and easy to understand for normal operation. If there’s any situation that really demands it, you can (and probably should) violate your own rules. Just be sure to have everybody involved and aware of your punctual actions and its impact.

Be happy

Source code management should make you happy. Both in the present and in the future. If you having too much pain figuring out what going on, committing and sharing your changes or make sense of the past, figure out what’s causing you such pain and how you could be doing things differently.

Remember, this tool is more than appropriate to handle big projects like the Linux kernel. They’re not in pain, and so shouldn’t you.

This guy says just that. I don’t find his conclusions all that groundbreaking. But I really loved his focus on “It’s a record store”.

I’m pretty sure that’s not there is to it being a success. He, disguisedly, says that curating your content is fundamental. And he’ll charge you for that.

Via A Better Mess

<script>
$(document).ready(function(){
    jQuery.extend(jQuery.expr[':'], {
      containsIgnoreCase:
        "(a.textContent||a.innerText||jQuery(a).text()||'').toLowerCase().indexOf((m[3]||'').toLowerCase())>=0"
    });
    $('input.filterer').keyup(function(){
        $('#'+$(this).attr('target_id')+' option').show().not(':containsIgnoreCase('+$(this).val()+')').hide()
    });
});
</script>
<input class="filterer" target_id="target_select_id" type="text"/>

But then IE made me do:

<script>
$(document).ready(function(){
    jQuery.extend(jQuery.expr[':'], {
      containsIgnoreCase:
        "(a.textContent||a.innerText||jQuery(a).text()||'').toLowerCase().indexOf((m[3]||'').toLowerCase())>=0"
    });
    $('input.filterer').each(function(){
        $('<select id="'+$(this).attr('target_id')+'_stash" style="display:none;" />')
            .insertBefore($('#'+$(this).attr('target_id')));
    });
    $('input.filterer').keyup(function(){
	var visible_select = '#'+$(this).attr('target_id');
	var hidden_select = visible_select+'_stash';
	var needle = $(this).val();
	$(visible_select+' option').not(':containsIgnoreCase('+needle+')').remove()
            .appendTo($(hidden_select)).removeAttr('selected');
	$(hidden_select+' option:containsIgnoreCase('+needle+')').remove()
            .appendTo($(visible_select)).removeAttr('selected');
    });
});
</script>
<input class="filterer" target_id="target_select_id" type="text"/>

I updated the drivers, and the lag dropped a bit, but not that much. Then I turned to KbdMgr.exe. I read that a quick fix was to set the affinity to the second core and set it to minimum priority. And so I did, and it worked! However, It was just a pain in the butt to do that dance on each boot. I thought of doing some wrapper exe for KbdMgr.exe, but just the thought of downloading Visual Studio and all the SDKs gave me nauseas. And python popped into my mind.

After some 15 minutes of research, I found win32all. And from there, It was just remembering all of the win32 I had forgotten. I eventually churned out some code to scratch my itch.

import win32api
import win32com.client
import win32process
import win32con
import time
import sys, traceback

class ProcessSeekerThrottler(object):

    def __init__(self):
        self.coup_de_grace = self.throttle_and_set_affinity
        self.backoff_interval = 1.0

    def throttle_and_set_affinity(self,pid):
        proc = win32api.OpenProcess(win32con.PROCESS_SET_INFORMATION, 0, pid)

        win32process.SetProcessAffinityMask(proc,0x02)
        win32process.SetPriorityClass(proc,win32process.IDLE_PRIORITY_CLASS)

        win32api.CloseHandle(proc)

    def pids_for(self,process_name):
        self.WMI = win32com.client.GetObject('winmgmts:')
        results = self.WMI.ExecQuery('select * from Win32_Process where Name="%s"'%(process_name,))
        if len(results) < 1:
            raise Exception("Not found: %s"%(process_name,))
        else:
            return [result.Properties_('ProcessId').Value for result in results]

    def hunt_pid_for(self,process_name):
        done = False
        while not done:
            try:
                [self.coup_de_grace(pid) for pid in self.pids_for(process_name)]
                print "Killed!"
                done = True
            except Exception as e:
                print >> sys.stderr, "-"*60
                traceback.print_exc(None,sys.stderr)
                print >> sys.stderr, "Backing off."
                time.sleep(self.backoff_interval)

if __name__ == '__main__':
    try:
        ProcessSeekerThrottler().hunt_pid_for("KbdMgr.exe")
    except Exception as e:
        traceback.print_exc(None,sys.stderr)
        raw_input()

• Shelve: No more diff mangling.
• Bookmarks: A pretty good interpretation on what local branches should be. Matches perfectly with my idea of them.
• Win32text: No more newline mambo-jumbo.

Enjoy them too!

Because I keep forgetting.

In this post: Why I use Mercurial (sometimes abbreviated as hg) but not Git, and why I like it.

One day, some moons ago, I watched a presentation with Linus on Git, and how it would forever change our life. He explained why it’s a must-use on a very big distributed team or/and at a personal level. I mostly agreed. I still thought this was just a clever hack to solve merge conflits on svn and keep changes controlled on a mental level. CVS is dead, SVN is not. For most small teams, SVN is just a shortcut for the common workflow one would do with git, except for one little thing: you commit locally, and publish as needed.

Mercurial, or any DSCM, is great for detaching the act of committing work (accepting it as a valid step towards a goal) from the act of publishing work (putting your modifications up for other parties).

I prefer Mercurial over Git for the polish and supporting the anti-”linus is god” movement. I really didn’t like the way I was told he dismissed the idea of using incremental logs. I’m not being an extremist, or i would use Codeville.

So I came up with this decorator.

import functools
import cPickle
def memoize(fctn):
        memory = {}
        @functools.wraps(fctn)
        def memo(*args,**kwargs):
                haxh = cPickle.dumps((args, sorted(kwargs.iteritems())))

                if haxh not in memory:
                        memory[haxh] = fctn(*args,**kwargs)

                return memory[haxh]
        if memo.__doc__:
            memo.__doc__ = "\n".join([memo.__doc__,"This function is memoized."])
        return memo

Python is really easy to write.

23 August 2008 – Update: Corrected the bug pointed out by John.
25 August 2008 – Update: Improved as per reddit comments‘s suggestions.

But that was my last step in my trail of Chandler faith. As soon as Chandler Desktop booted up, I was greeted with a soft, warm and fuzzy python exception: “Hey! This function receives one argument, you gave it two!”. Never good.

Tried to report the bug. Need a login for some bugzilla somewhere. Hmm, guess I’ll pass.

And don’t think that I am saying that there is no place for optimization, that is not true, there is just less room for optimization in the source itself, but there is lots of room for optimizations in terms of overall system performance and in terms of developer productivity. It is more important to focus on the big picture and solve performance problems that are system wide, or refactor code so that changes can be made much faster, than it is to solve a performance problem in a single line of code…unless of course that line of code is being called 8 million times by 50 parts of the system.

So next time you go to write a super clever line of code, think to yourself “Will the benefits of this super cleverness be outweighed by the future issues in maintaining and understanding the code?” And if there is any hesitation at all, then you better not be clever, because 3 months from now you will come across that code and say “What the hell was I thinking?” Then you’ll end up rewriting it anyway.

It’s quite correct, except for one little detail: “Then you’ll end up rewriting it anyway”.

I wish! Doing it right the first time is the good solution, but rewriting it when you latter come across it and realise it’s stupid is a “not good, not bad” solution. The problem is when you just can’t rewrite that piece of crap! Maybe you can’t test it, maybe you have something more important to do, maybe you don’t really understand it, maybe maybe maybe…

I could segway this into the perfect TDD and “Tests as a living, runnable spec” pitch, but I’ll let it rest.