On Sun, 11 Jun 2006, Linus Torvalds wrote: > > See? No renames. The renames is not what is fundamental here. What is > fundamental is the _STATE_ of the tree. Remember: that's what git tracks, > and that is what "git log" shows you. Btw, this is also why I suggested adding a "--no-simplify-history" flag, because in this case, that's exactly what _you_ want. The reason git is doing something unexpected - and in your case inferior - is exactly that what you want in this case is really not "explain the STATE of this file", but you want "give me ALL THE HISTORY concerning this filename". Both are very valid things to ask for, it just happens that "git log" by default answers the _other_ question. It does NOT answer the "what is all the history" question that you're asking, it answers the "how did this state come to be" question. Btw, the original "git whatchanged -p" answered exactly the question you had, and the semantics changed when we rewrite "git whatchanged" to act like "git log -p". But you can still get the old semantics by hand, if you really want it, by doing git-rev-list --all | git-diff-tree -p -- <filename> because (and this actually makes total sense when you look at it), you now actually say "first give me all the history" and then "show the actual changes in that history as it pertains to <filename>". See? I hope this explains the not-so-subtle (but still easy to overlook) difference between the two. And I do agree that we should teach "git log" and friends to be able to answer both questions, and that's what my suggested patch (fleshed out properly, of course) should do. Not that I ever _tested_ it, of course. Me? Testing? You make me laugh. Ho Ho Ho. Linus - : 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