Re: file rename causes history to disappear

On Wed, 6 Sep 2006, Jeff Garzik wrote:

Sure, if you don't actually want the diff, the "-M" isn't worthwhile.

No, it should not. 

You haven't thought it through, and I excuse you, because even people who should know better (and design SCM's) often haven't thought it through.

There's a huge difference between "pathname" and "inode". And git operates on _pathnames_, not on inodes. So when you give a pathname specifier, that's _exactly_ what it is. It's a pathname specifier, _not_ an "inode" specifier.

And pathnames don't change. They're just names for paths to possibly _find_ a file/inode. They can't be "renamed". The data that is found behind a pathname may be moved to _another_ pathname (and we call that a rename), but that doesn't change the original pathname in any way, shape, or form.

Now, you can say "git shouldn't work with pathnames, it should work with inodes, and use the pathnames to look them up", but you'd be wrong. You'd be wrong for many reasons, so let me explain:

 - pathnames are actually often a hell of a lot more interesting that 
   "inodes". Doing thing by pathname means that you have sane and 
   well-defined semantics for something like

	git log -- drivers/scsi drivers/ata include/linux/ata.h

   even if (for example) some of those files or directories don't 
   necessarily even exist at one particular point in time. Exactly 
   _because_ a pathname is not actually affected by the contents of the 
   repository.

   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.

 - following inodes/files instead of following pathnames happens to also 
   be fundamentally ambiguous when you split or merge the file contents. 
   What happens? You simply _cannot_ describe that in the form of "files". 
   It's impossible. Really. Yet it's actually fairly common.

   In contrast, if you think of pathnames of _pathnames_ (rather than the 
   contents they point to), that particular sticky wicket simply doesn't 
   exist. It's a non-issue. File contents that get split? Big deal. We 
   don't care. We care about a particular set of pathnames, and if the 
   file content came from (or got split into) that set of pathnames, we 
   show it.

So thinking in terms of pathnames is not only fundamentally more powerful, it also very fundamentally avoids a confusing situation that you cannot avoid with a "inode" based model.

You just need to get used to the fact that the arguments you give to "git log" and friends really have _nothing_ to do with any particular "file" or "content at any particular time". They are immutable path specifiers. When you say

	git log -- drivers/scsi/libata.c

you're asking git "tell me what happened to this _pathname_". Not file. Not content (although if you ask for diffs it will show you the diff, but not for that "file", but simple AS IT PERTAINS TO THAT PATHNAME!)

It may take a bit of getting used to, but once you realize that git talks about immutable pathnames, and once you do get used to it, it's a hell of a powerful thing.

And then we can have "--follow-renames" when we are lazy and we _understand_ that git talks about pathnames, but we want git to show us the data _as_if_ it cared about how the inodes moved around.

			Linus