On Wed, May 7, 2025 at 4:23 PM Marc Branchaud [off-list ref] wrote:

On 2025-05-07 10:22, Toon Claes wrote:

quoted

Marc Branchaud [off-list ref] 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.

quoted

quoted

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