Re: file rename causes history to disappear

From: Linus Torvalds <torvalds@osdl.org>
Date: Sep 6, 2006, 16:37 UTC
Message-ID: <Pine.LNX.4.64.0609060922110.27779@g5.osdl.org>
In-Reply-To: <Pine.LNX.4.64.0609060858050.27779@g5.osdl.org>

On Wed, 6 Sep 2006, Linus Torvalds wrote:

Show 6 quoted lines

> 
> 	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