On Wed, May 7, 2025, at 22:23, Marc Branchaud wrote: > 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. Use a Git user I don’t see the problem. `git --list-cmds=builtins` lists 144 commands. Six of them are `-tree` commands. It’s not been my understanding that people stumble upon niche commands that easily. Most questions I’ve seen about git-commit-tree(1) (one of the `-tree` commands that seems to come up from time to time) seem to come from a point of idle curiosity. That’s questions that bring it up (i.e. potential user confusion). (The first impression I got of `-tree` commands was that they were less user-friendly commands for hardcore users.) That’s just my perspective. Do you have a case in mind where such a new command could lead to user confusion?
