Re: [PATCH RFC 0/5] Introduce git-blame-tree(1) command

> Toon Claes <toon@iotcl.com> 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.