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

[Junio C Hamano <gitster@pobox.com>]

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.

Thanks.