On Wed, May 7, 2025, at 22:23, Marc Branchaud wrote:

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

quoted

Marc Branchaud [off-list ref] writes:

quoted

I feel the need to get some bike-shedding off my chest, though:

Always welcome!

quoted

"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.

quoted

quoted

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?