Toon Claes <toon@xxxxxxxxx> writes: >>> I thought you switch to blame-at-the-file-level only when you are >>> given a directory (or a tree)? "git blame path/to/file" has ALWAYS >>> done "blame these lines that appear in this file", and cannot change. > > I don't know about that. What if you want to blame multiple files: > > $ git blame-tree refs.c refs.h I do not mind "multiple files mean blame-tree mode" as a yet another heuristics to tell which mode we are talking about, as "blame these lines" mode would take just one pathname to a blob and never a tree. But the topic, IIRC, was about how "git blame" (with 'blame-tree' feature rolled into it) can tell which mode the request by the user is about. So you should have said "git blame refs.c refs.h" above. > or (letting your shell do the globbing): > > $ $ git blame-tree *.h This one (with command name corrected) is questionable, as there could be a case where there is a single .h file, in which case, the command line would become "git blame that-single-header-file.h". Again, I do not mind "even though I may have only a single blob specified on the command line, I want the blame-tree mode" command line option. So to recap $ git blame path-to-dir ;# blame-tree mode for paths in the directory $ git blame path1 path2 ;# blame-tree mode $ git blame path ;# traditional blame-these-lines mode $ git blame --tree path ;# blame-tree mode $ git blame --tree path1 path2 ;# blame-tree mode would work fine. Having said that, I personally do not think of what "blame-tree" does as "blame" at all, and there should be a better name for that operation that does not use "blame" or "annotate". So a separate command that does not even hint it has any relationship with "blame" (because it doesn't; in my mental model, it does not do any "blame" at all---it just does "git log -1 path" for many paths in parallel) would be even more preferrable. Thanks.
