On Sun, 26 Mar 2006, Petr Baudis wrote: > > Huh? I don't see that now (and caps don't help me see it better). That's > certainly not what is in [1], and I don't see _how_ to detect the > renames in this case, and what would I be actually doing git-ls-tree for > when I've already detected the rename. Based on [1], I'd be doing > git-ls-tree merely to detect that a file _disappeared_ in the first > place, I have to do other stuff to detect the renames themselves. No, the point is that "git-rev-list" already does all of [1] in the core. If you do git-rev-list --parents --remove-empty $REV -- $filename then you'll get the whole history for that filename. When it ends, you know the file went away, and then you do basically _one_ "where the hell did it go" thing. And yes, it's not git-ls-tree (unless you only want to follow pure renames), it's actually one "git-diff-tree -M $lastrev". Then you just continue with the new filename (and do another "git-rev-list" until you hit the next rename). 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