On Wed, 6 Sep 2006, Linus Torvalds wrote: > > git log -- drivers/scsi drivers/ata include/linux/ata.h > > So taking a filename-based approach is actually more _powerful_. You > can emulate the "follow a single file" behaviour on top of it, but you > can't sanely go the other way. Side note: one thing that I wanted to do, but never got around to, is to allow wildcards in the tree-parsing code. It might be too expensive, but it's still occasionally something I'd like to do: git log -- 'mm/*.c' to track every single C file in the VM (even if they don't exist right _now_). Notice the difference between git log mm/*.c and the above idea - the latter does actually work, but it only tracks the C files that exist right now under mm/. But it should be possible (and is potentially useful) to let the wildcard act over the history, rather than just a single point in time. Because one additional advantage of thinking in terms of pathnames is exactly the fact that wildcards make sense in a way that they do _not_ make sense if you think of tracking "inodes". Exactly because "pathnames are forever", and a pathname has validity and exists regardless of whether a repository contains a _file_ with that name at any particular point in time. So right now git does do the wildcard thing, but only for "git ls-files" (and through that, things like "git add", which used to be implemented in terms of ls-files). So you can do git add '*.c' to add all C files (recursively - it's not the shell matcher). Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html