On 2025-05-07 16:45, Junio C Hamano wrote:
Marc Branchaud <marcnarc@xxxxxxxxxxx> writes:
I mean, from a usability point of view, it makes much more sense if
"git blame" simply understood how to handle blaming a directory
differently from blaming a file/blob:
I think this needs rephrasing: blaming a whole file (or a whole
tree) differently from blaming individual lines.
As lines can move across files, and we do find such moves while
tracing the origin of each line, "blaming a file" is not quite the
right way to think about it. "blaming lines in a file", perhaps.
I see what you mean. "Blaming lines in a file" works for me.
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?
While a "whole-file blame" is really just
git log -1 path/to/file
I can appreciate the convenience of being able to do that with "git
blame". I suggest adding an option for this specific case, like maybe
"--latest" (I don't feel strongly about the option's name).
Want to see the annotated blamed lines of a file?
git blame path/to/file
Want to see the last commit to touch a file?
git blame --latest path/to/file
or
git log -1 path/to/file
Want to see the last commits to touch each file under a directory?
git blame path/to/directory
(--latest is implied because the target is a directory.)
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.
M.
