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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2025-05-15 09:29, Patrick Steinhardt wrote:
On Wed, May 14, 2025 at 05:15:30PM -0400, Marc Branchaud wrote:
On 2025-05-14 15:29, Junio C Hamano wrote:
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.

Curious. Isn't it exactly the same what git-blame(1) does though? Taken
the textual representation of a tree object, we figure out when each of
the lines has last been changed. That to me sounds like exactly the same
thing as git-blame(1), but just for trees instead of for blobs.

Sure, git-blame-tree(1) goes further than that. But conceptually it is
exactly the above thing, isn't it?

I think the operation can be perceived in different ways. My only point is that if we do conclude that it is a form of blaming then we fold it into "git blame" instead of a new command.

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"?

I think anything that needs a thesaurus to come up with probably isn't a
good name for non-native speakers. I personally had to look up what this
word means.

Yeah, that was a bit tongue-in-cheek, sorry.

(Honestly, "ascribe" would be really bad, precisely because it is a synonym of "blame"...)

		M.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux