On 2025-05-08 10:26, Junio C Hamano wrote:
Marc Branchaud <marcnarc@xxxxxxxxxxx> writes:
This distinction brings up a wrinkle in my proposed DWIMery: should
git blame path/to/file
show the annotated blamed lines of the file, or simply display the
last commit that changed the file?
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.
Of course you can say "git blame path/to/ | grep file"; as you said
yourself,
git log -1 path/to/file
is so obvious, we do not need to introduce yet another way to get to
the same information, I think.
Fine by me. I personally don't think of "git blame" when I want to see
a file's commit history.
It also occurs to me that
git blame path/to/directory
might need a way to toggle recursion. I suggest recursion be off by
default.
I do not have strong opinion on this part; I've somehow assumed
while reading your message that you wanted it to always recurse
(like `git ls-files` does) and I thought it made sense, but not
recursing and just showing a single level (like `git ls-tree` does)
with an option to make it recurse is certainly a possibility.
I also don't feel strongly either way. It just seemed that defaulting
to recursion could end up creating a lot of processing (and output), and
that making the user explicitly ask for it seems friendly.
But whatever the default is, it does seem useful to have an option to
control recursion.
M.
