On 2025-05-14 15:29, Junio C Hamano wrote:
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.
I'd be happy with all of that.
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.
I'd also be happy if instead this came in as a new command without
"blame" in its name.
How about [[consults thesaurus ...]] "git ascribe-tree"?
Or maybe fold it into ls-tree, e.g. "git ls-tree --ascribe"?
M.
