1. The commit truly introduced the block of code. The author of the commit was the inventor of that cool feature you were hunting its origin for (or the guilty party who introduced the bug); or
2. The block of code did not exist in the file, but five identical copies of it existed in different files, all of which disappeared after the commit. The author of the commit refactored duplicated code by introducing a single helper function; or
3. (as a special case) Before the commit, the file that currently contains the block of the code you are interested in itself did not exist, but another file with nearly identical contents did exist, and the block of the code you are interested in, together with all the other contents in the file existed back then, did exist in that other file. It went away after the commit. The author of the commit renamed the file while giving it a minor modification.

1. Fast path-limited revision traversal

arch/           drivers/   ipc/         mm/             security/
block/          firmware/  Kbuild       net/            sound/
COPYING         fs/        kernel/      README          tools/
CREDITS                    lib/         REPORTING-BUGS  usr/
crypto/         include/   MAINTAINERS  samples/        virt/
Documentation/  init/      Makefile     scripts/

$ git log v2.6.30 -- arch/x86/mm/init.c

2. Merge Simplification

          *   *
      E---D---C---B---A
     /           /
 ---I---H---G---F

          *   *
      E---D---C---B---A
     /
 ---I

3. Pickaxe

struct map_range {
        unsigned long start;
        unsigned long end;
        unsigned page_size_mask;
};

$ git log --pretty=short -S'struct map_range {
        unsigned long start;
        unsigned long end;
        unsigned page_size_mask;
};' v2.6.30 -- arch/x86/mm/init.c

4. Blame

1. Content movement from other files is identified naturally, albeit that we identify only one single source (i.e. we do not notice that the block of text is a result of refactoring five identical copies); and
2. Wholesale file rename falls out as a trivial and very narrow special case of (1) without recording any rename tracking information at the commit time.

5. GUI

1. Show the contents of any file in the tree, and let you highlight with mouse/keyboard a block of text in it;
2. Run the path-limited pickaxe search to find the commit that touches the block of text you showed interest in step (1). We already have both of the two necessary ingredients needed to perform this step efficiently.
3. Show the change of the commit found in step (2), and find blocks of text in the files in the tree of the parents' of the commit that match or are very similar to what we are interested in. We do have GUI that shows the change of the commit; we do not have a good tool (yet) to show similar blocks of text that are potential pre-refactored duplications to identify refactoring. Perhaps we could run (possibly fuzzy) grep in the tree of the parent commits. We have already a capability to run grep on a tree object.
4. Let you go back to step (1), starting from the commit we inspected in step (3) and continue.

• Virtual disks for VM instances
• "git new-workdir" build area for each branch
• temporary (downloaded ISO images, torrents, etc.)

• /, /usr, /var, /home, ...
• Project repositories and work trees
• Daily snapshots of the above, including VM virtual disks.

• Debian 5.0 (i386)
• Fedora 9 (i386); I need to keep one to cut RPMs for k.org
• Fedora 11 (i386 and possibly x86_64); in preparation for the day k.org upgrades, perhaps
• FreeBSD 7.2 (i386 and possibly x86_64)
• OpenBSD 4.5 (i386)
• OpenSolaris 0811 (i386)
• Some vintage of Windows to try msysgit out (undecided, as I am not a Windows person)