From: Marc Branchaud <marcnarc@xiplink.com>
Date: Thu, 08 May 2025 13:26:01 GMT
Subject: Re: [PATCH RFC 0/5] Introduce git-blame-tree(1) command
Message-ID: <7a6afafc-6dee-4a09-8779-83748a4d3fc4@xiplink.com>
In-Reply-To: <xmqqjz6sb15u.fsf@gitster.g>


On 2025-05-07 16:45, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> 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.