From: Marc Branchaud Date: Wed, 14 May 2025 21:15:30 GMT Subject: Re: [PATCH RFC 0/5] Introduce git-blame-tree(1) command Message-ID: <0f491261-bbe1-474d-a240-0ddbf22cc754@xiplink.com> In-Reply-To: On 2025-05-14 15:29, Junio C Hamano wrote: > Toon Claes writes: > >>>> 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. >> >> I don't know about that. What if you want to blame multiple files: >> >> $ git blame-tree refs.c refs.h > > I do not mind "multiple files mean blame-tree mode" as a yet another > heuristics to tell which mode we are talking about, as "blame these > lines" mode would take just one pathname to a blob and never a tree. > > But the topic, IIRC, was about how "git blame" (with 'blame-tree' > feature rolled into it) can tell which mode the request by the user > is about. So you should have said "git blame refs.c refs.h" above. > >> or (letting your shell do the globbing): >> >> $ $ git blame-tree *.h > > This one (with command name corrected) is questionable, as there > could be a case where there is a single .h file, in which case, the > command line would become "git blame that-single-header-file.h". > > Again, I do not mind "even though I may have only a single blob > specified on the command line, I want the blame-tree mode" command > line option. So to recap > > $ git blame path-to-dir ;# blame-tree mode for paths in the directory > $ git blame path1 path2 ;# blame-tree mode > $ git blame path ;# traditional blame-these-lines mode > $ git blame --tree path ;# blame-tree mode > $ git blame --tree path1 path2 ;# blame-tree mode > > would work fine. I'd be happy with all of that. > 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. 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"? M.