On Wed, 6 Sep 2006, Jeff Garzik wrote: > > Since I'm just interested in the log (ATM), even the lack of "-M" seems to > produce useful results. Thanks. Sure, if you don't actually want the diff, the "-M" isn't worthwhile. > IMO it is highly counter-intuitive that renames are -not- followed. I don't > see the point of a "--follow-rename", it should Just Work(tm). 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 - 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