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

From: Patrick Steinhardt <ps@pks.im>
Date: May 15, 2025, 13:29 UTC
Message-ID: <aCXsKHiP4uIzCMrt@pks.im>
In-Reply-To: <0f491261-bbe1-474d-a240-0ddbf22cc754@xiplink.com>

On Wed, May 14, 2025 at 05:15:30PM -0400, Marc Branchaud wrote:

Show 8 quoted lines

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

Show 6 quoted lines

> 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.

Patrick