Greppin’ in the past with git

It seems that one can never stop learning new things with git, no matter for how long you’ve been using it (in my case, I’m a proud git user since 2008), because today I added a new trick to my toolbox, that already proved to be quite useful: “grepping” files in a git repository, as you would do it with git grep, but using a commit-id to limit the search to a specific snapshot of your project.

In other words, I found that it’s possible to do things like, say, grep files to search for something in your repository considering how it was, say, some commits ago.

This is the “magical” command:

    git grep <search-params> <tree-id>

This is what I get if I try to search for updateBackingStore() in my local clone of WebKit, as if my current branch was “50 commits older” than what it actually is:

$ git grep updateBackingStore HEAD~50
0ae236137d560da6ca889a826a8f3d023364a669:AccessibilityObject.cpp:void AccessibilityObject::updateBackingStore()
0ae236137d560da6ca889a826a8f3d023364a669:AccessibilityObject.h:    void updateBackingStore();
0ae236137d560da6ca889a826a8f3d023364a669:AccessibilityObject.h:inline void AccessibilityObject::updateBackingStore() { }
0ae236137d560da6ca889a826a8f3d023364a669:atk/WebKitAccessibleUtil.h:        coreObject->updateBackingStore(); \
0ae236137d560da6ca889a826a8f3d023364a669:atk/WebKitAccessibleUtil.h:        coreObject->updateBackingStore(); \
0ae236137d560da6ca889a826a8f3d023364a669:atk/WebKitAccessibleWrapperAtk.cpp:    coreObject->updateBackingStore();
0ae236137d560da6ca889a826a8f3d023364a669:ios/WebAccessibilityObjectWrapperIOS.mm:    m_object->updateBackingStore();
0ae236137d560da6ca889a826a8f3d023364a669:ios/WebAccessibilityObjectWrapperIOS.mm:    m_object->updateBackingStore();
0ae236137d560da6ca889a826a8f3d023364a669:mac/WebAccessibilityObjectWrapperBase.mm:    // Calling updateBackingStore() can invalidate this element so self must be retained.
0ae236137d560da6ca889a826a8f3d023364a669:mac/WebAccessibilityObjectWrapperBase.mm:    m_object->updateBackingStore();

I don’t know about you, but I find this quite useful for me to answer questions such as “Where was this function being used in commit X?”, and things like that.

Anyway, you might have noticed that I mentioned <tree-id> in the recipe instead of <commit-id>, yet I used HEAD~50 in the example, which is actually a commit-id. And still works.

And the short explanation, without trying to explain here all the different kind of data types that git keeps internally for every repository (mainly commitstrees and blobs), is that git is smart enough to find the right tree-id associated to a given commit-id by just considering the current path inside the repository and the tree-id associated to the top directory for a given commit.

But how to know that tree-id myself in case I want to? Easy, just pretty print the full information of the commit object you’re interested in, instead of only seeing the abbreviated version (what you usually see with git show or git log:

$ git cat-file -p HEAD~50
tree 0ae236137d560da6ca889a826a8f3d023364a669
parent bdb7a7949a29988da3fe50a65d6c694d5084d379
author [...]

See that tree thing in the first line? That’s the tree-id that git needs for grepping, which as you can see can be easily extracted from a particular commit. Actually, you could get easily the tree-id for any subdirectory from this point, by using the git ls-tree command:

$ git ls-tree 0ae236137d560da6ca889a826a8f3d023364a669
100644 blob 3fe2340c9614e893f0dfeb720f23773bbf1ea076	.dir-locals.el
100644 blob 741c4d53b5a0338cf36900a283e89408d0f9d457	.gitattributes
100644 blob f45a975762be9a429aa971c18da01b433c559553	.gitignore
100644 blob d571aa28ea86c14c7880533bf3ba68e9ef4b3c81	.qmake.conf
100644 blob 10f85055ae9f3823f0d20808599f644c18af7921	CMakeLists.txt
100644 blob 5eb66e7bcbc7543eb3a4dbf183a9043545776659	ChangeLog
100644 blob 7dbe9d2e0029bab47b8b2b22065a1032ecfe4434	ChangeLog-2012-05-22
040000 tree d42a0b3121ed7993cfd250426d20472769760f87	Examples
100644 blob 78d89e5c70ad56c38b0c25e7705d42fa380c4ee0	GNUmakefile.am
040000 tree 4a9e87fc1f35efa1349a18b1df694530c981c57e	LayoutTests
100644 blob 14e33157011157797dac62c494bac0bf254d7c2f	Makefile
100644 blob ee723d830dea51d1ce9e2d1ad8c985eeca2d4f3f	Makefile.shared
040000 tree 20c763d6a4e8749ad9e041e8372e9f47dc722f45	ManualTests
040000 tree 660d88b926cf618ab9e1612b8e2a3e97b15dbcbe	PerformanceTests
040000 tree fbf9703d3e9a9e4cf2ff10817c99ba3a5de87410	Source
040000 tree 346110c441a674334f5f56ef42b9dd40def89c76	Tools
040000 tree 262cb11d9b491be35daee570f9b825bce5715579	WebKit.xcworkspace
040000 tree b9e48a7a24b4973b253ee14053808b40d67c94aa	WebKitLibraries
040000 tree adce37b690957abdd21d2dd8ff77302c5a5a9071	Websites
100755 blob befd429487fc5ac9bb3494800f4eeaef1e607663	autogen.sh

And of course, “navigating” with more calls to git ls-tree you could also get the tree-id for a specific subdirectory, in case you wanted to constraint the search to that specific path of your repo.

However, considering that git is so good at translating a commit-id into a tree-id, my personal recommendation is that, instead, you first cd into the path you want to focus the search in, and then let git  do its “magic” by just using the git grep <search-params> <tree-id> command.

So that’s it. Hope you find this useful, and please do not hesitate to share any comment or suggestion you might have with regard to this or any other “git trick” you might know.

I honestly love using git so much that sometimes I wonder if coding is not just a poor excuse to use git. Probably not, but the thing is that I can not imagine my life without it anymore. That’s a fact.

Multiple cursors, Emacs and me

It’s been 7 years already since I started using Emacs and, for some reason, I still haven’t found a text editor I do feel more comfortable with, and I Swear to Gods I’ve tried. I really did. And as proof, I can tell that those who know me a bit can really support this statement, no doubt about it ;)

The thing is that,  for some reason or another, whenever I tried a different editor, a fancy IDE or anything else, the result was always the same: I first realize of a new and very interesting feature X in the editor Y which makes me think for a while “hmmm… this could be the one”, then I start using that editor Y for a while, then I realize I’m not comfortable enough for many other things, then I realize I’m continuously alternating between that editor and Emacs and then… finally… I somehow manage to “port” that very nice feature X to Emacs and ditch editor Y to finally come back to the origin again.

And that has been the story of my (text editing) life so far. And, as you can see, I haven’t written a blog post about every single feature X I added to my Emacs. But this time is different.

Everything started, as usual, with me willing to try a new text editor, and this time I selected Sublime Text 2 as the one to check, mainly because I wanted to check myself whether of all the hype around it was justified or whether it was just… well… just hype.

And I have to say that I was really impressed by ST2: what I’ve seen is a very nice and modern editor which is blazingly fast and convenient to use, and which on top of that it comes with a lot of useful features and a nice configuration out-of-the box, which is also very easy to customize and extend if you want to. Up to that moment, everything seemed to suggest I could be really in front of a replacement for Emacs, but given my past experiences I still took this with a grain of salt (even if I could not hide my excitement either)…

If you don’t believe me, you should really checkout its website and, even better, the “Perfect Workflow in Sublime Text2″ tutorial and you will see yourself what I’m talking about.

However, not all were bells and whistles in my ST2 experience. There were drawbacks too, and the main ones I could see were that it was not an Open Source editor and that the bus-factor was really scary (only one developer, I think). And those two things together were a serious concern to me. But I tried it anyway, because it really feel like it could be a serious competitor for my Emacs, and I was willing to take the risk, just for the sake of checking it (and playing around with a new editor, which I confess is something I love doing every now and then in any case).

But yet again, the same pattern happened one more time: I found myself loving ST2 in many regards but alternating too often between it and Emacs since, even if ST2 was lovely for many things, there was nothing that was really convincing me of replacing my Emacs in favour of it. Well, almost nothing… because the “multiple cursors” feature in ST2 got my attention as not many text editor features got it in the last years.

So, the obvious step at this point, having already decided that I would be going back to Emacs again, would be to try to port this nice feature to Emacs, and then I found the awesome “Emacs Rocks!” site, where I found a demonstration of this sleek feature working inside Emacs. I´ll leave the link to the video here, so you can really see what all this is about:

As you can see, this feature is amazingly useful for many things of everyone’s life (well, maybe not really everyone’s, but almost!), as it’s incredibly helpful for things like massive “search & replace”, improving code structure (e.g. break a list of strings in one single line into multiple ones) and many other situations.

Others might disagree, of course, but for me there’s a “before” and an “after” I knew about this feature, and I don’t think I will be able to easily move now to an editor which doesn’t have something like this available in some way.

Should you want to try it out yourself, I recommend you to check out both episode 13 in “Emacs Rocks!” as well as the github repository where you’ll find the package for Emacs.

Guess this means I’ll stick to Emacs for some more time after all, even if I’m still not sure I will stick forever to it, since I can’t say either I’m 100% comfortable with it, just that it’s the best thing I’ve found so far. Yet I can’t avoid feeling that I still haven’t found what I’m looking for

Screen redrawing problems with the “nvidia” driver and Compiz

Just in case you were experiencing, like me, some very annoying problems with your NVIDIA graphic card while using Compiz, here you have a very useful option to put inside the “Device” section in your /etc/X11/xorg.org file:

Option         "UseCompositeWrapper" "true"

After activating this option (available for nvidia drivers >= 169.xx) I found that the problems redrawing windows I was suffering, specially when scrolling (very annoying, for instance, when chatting through pidging), just dissapeared. And it was indeed a very annoying problem, since it used to happen very often and in almost any window (although not in Emacs ;-) ) in my system, in a way so any information on it just got screwed up so it was completely unreadable… and the only “manual” workaround I had found so far was just to re-scroll the window or select the text I was trying to read, which seemed not to be a very good idea.

Needed to say that I started to see this odd behavior since I “downgraded” my Ubuntu 8.10 down to 8.04 last week (because of some very specific needs), and this strange problem never happened when using Intrepid, so if you’re now using that version perhaps you can just throw this post away to the trash, because then it would not useful at all for you.

But just in case, here you are my two cents, and to make them even more useful, here you are the full configuration of my “Device” section in /etc/X11/xorg.conf, which allows me to use a fully accelerated desktop with no problems at all:

Section "Device"
    Identifier     "Videocard0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "Quadro NVS 140M"
    Option         "AllowGLXWithComposite" "true"
    Option         "UseCompositeWrapper" "true"
    Option         "XAANoOffscreenPixmaps"
    Option         "NoLogo" "true"
    Option         "backingstore" "true"
    Option         "TripleBuffer" "true"
    Option         "AddARGBGLXVisuals"  "true"
EndSection

Hope this will be useful for you as well :-) .

Update: If you’re still suffering these problems even after adding these lines to xorg.conf, you could try to install the nvidia driver through Envy. These steps worked for me (at the end, the annoying problem appeared again, although not so often than before):

  1. Uninstall any other driver you had installed before (through the ubuntu “restricted drivers” manager, or the .run script downloaded from nvidia.com).
  2. Install Envy: apt-get install envyng-core
  3. Shutdown X and install the nvidia driver from a tty terminal: envyng -t

After following these steps, and the simple instructions on screen, by ubuntu hardy perfectly booted up with the nvidia driver v173.14, which seems not to present the same problem.

Let’s see if these new advice helps you too :-)