On Wed, May 7, 2025 at 4:23 PM Marc Branchaud <marcnarc@xxxxxxxxxxx> wrote: > > > On 2025-05-07 10:22, Toon Claes wrote: > > Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: [cut] > I agree that blaming is a well-(known) concept. I also agree that most > users would understand what blame-tree would do, *once they find it*. > > But I think that's beside the point I'm trying to make. Git is > notorious for making users learn countless commands, and having two > slightly-different commands for blaming is just going to make that worse. > > 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: > > Want to see which commit last touched each line of a file? Just run > git blame path/to/file > > Want to see which commits last touched each file under a tree? Just run > git blame path/to/directory > > Git should be smart enough to figure out what to do from just whether or > not the last argument is a file or directory. I quite like this idea, too: today, "git blame t" in git.git is a fatal error, for example (no such path 't' in HEAD). (#leftoverbits: it's also not translated?) Turning an error into a new use case seems like an excellent expansion of capabilities. > > >> If this is really a form of blaming, then just make it an extension of > >> "git blame", like maybe "git blame --latest". > > > > I'm afraid that won't work very well, because the code is very much > > different. If naming is the only motivation to shoehorn this in, then I > > think it's better to rethink the name? > > It's not just "naming" but rather trying to help Git be intuitively > useful to users. > > Also, I think sacrificing usability because it makes the coding hard is > unfortunate. > > I personally think it's fine for blame.c to contain two different > internal swathes of code that do different things. The ~500 lines or so > to implement blame-tree don't feel like a major burden to me, especially > compared to the ~3000 lines already in blame.c... > > But if combining the two features into a single C file is too much to > bear, perhaps refactor the existing blame.c code? Something like: > > - blame-file.c (the existing "git blame" implementation) > - blame-tree.c (the new functionality) > - blame.c (exposes both blame-file and blame-tree under "git blame") A third alternative is to allow "git blame-tree" as here, but as plumbing. Then we have "git blame <dir>" use it—today, that might mean directly invoking "git blame-tree"; in the future, that might look more like the relationship between "diff" and "diff-tree" (assuming there is one)? -- D. Ben Knoble
