On Mon, 07 Jan 2008 13:04:34 -0800 Junio C Hamano <gitster@xxxxxxxxx> wrote: > That's asking for the history of a _path_ (or subset defined by > paths, as in "what changes were made to paths under 'arch/'"), > which is very different from asking "I have B/foo.c -- show me > the history of that _file_". > > Remember, David stated: > > >> ... So you cannot do git-log B/foo.c as git doesnot know where > >> to search it as it thinks it is in /foo.c not in B/foo.c ... > > Notice "as git does not know where to search it" part? > > Think --- what does that "it" refer to in that sentence? > > The statement is not about paths. If it were about paths, then > the output of "git log B/foo.c" does show what he wants. The > question "git log B/foo.c" asks is "what change were made to the > path at B/foo.c". The changes made to B/foo.c (i.e. what's > shown with the diff headers that begin with "--- a/B/foo.c") are > shown. The changes made to foo.c are not shown. > > But that is different from what David is asking. He wants to > know what changes were made to B/foo.c or to foo.c, and wants to > make the choice between the two depend on commit. The reason > you think you can pick between foo.c and B/foo.c is because > there is an illusion that somehow there is an i-node like file > identity that is kept track of, and it is preserved across > renames and merges. > > That's keeping track of the history of a _file_. > > And as you know, git doesn't do that. > > What git does is to keep track of the history of the whole tree, > but prune the parts that are not interesting away when you view > the history. And the pruning can be specified by _PATH_. > > See the difference? > Junio, Thanks for taking the time to answer, I know you're busy with much more pressing issues getting 1.5.4 out the door. You make the distinction between paths and files quite clear, and why it's important to keep in mind. In the case of the "--follow" option though, the user might be forgiven for thinking in terms of files rather than paths. Even the git-log documentation says for "--follow", "Continue listing the history of a file beyond renames". Which at least implies that Git knows about file history, rather than just paths. It's reasonable for a user to expect "git log --follow B/foo.c" to do The-Right-Thing in the subtree merge case. But I recognize that it would actually be rather difficult to implement, perhaps making it impractical. Cheers, Sean - 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
