On 2025-05-07 10:22, Toon Claes wrote:
Marc Branchaud <marcnarc@xxxxxxxxxxx> writes:
I feel the need to get some bike-shedding off my chest, though:
Always welcome!
"blame-tree" would be a terrible name for this command.
Do you feel this way because "blame" as a negative conotation?
Good question, but no, not at all.
My concern is about having two commands to do blaming (or "crediting" or
whatever anyone wants to call it), instead of just one.
I think that if Git ends up with two blame-like commands it will
merely solidify Git's reputation for obscurity.
I think "blaming" is a well-concept in Git, and many people (familiar
with Git) would understand in instant what `blame-tree` would do.
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.
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")
Otherwise, please come up with a new command name. "git latest"? "git
"latest-revs"? As long as it doesn't use the word "blame"...
I've been thinking about this a lot more, but I failed to come up with a
better name.
FYI, here's Peff's original explanation[1] of how he came up with the name:
> I wasn't sure at first what to call it or what the calling conventions
> should be. The initial thought was to make it part of "ls-tree". But
> that feels wrong, as ls-tree otherwise never cares about traversal.
> The combination of traversal and diff made me think of blame, and
> indeed, I think this is really just about blaming a whole tree at the
> file-level, rather than at the content-level. Thus I called it blame-
> tree, and I used the same calling conventions as blame:
> "git blame-tree <path> <rev opts>".
To me that reads like an argument for folding this into "git blame".
Forgive me, but I think folding into git-blame(1) will also solidify
Git's reputation of obscurity.
Please elaborate.
I think `blame-tree` is a fine name for this feature, but in the end I
don't care too much about the exact name. If we end up naming it `git
last-for-each`, `git annonate-files`, `git log-everyone`, or `git
when-modified` ... It's all good for me.
But then, why not just expand "git blame"?
I feel that the
git blame path/to/directory
use case I mentioned above is a compelling argument to fold the feature
into standard "git blame", aside from any reputation-for-obscurity
discussion.
M.
