Re: [PATCH RFC 0/5] Introduce git-blame-tree(1) command

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2025-04-22 13:46, Toon Claes wrote:
This is another attempt to upstream the git-blame-tree(1) subcommand.
After the previous attempt[1] the people of GitHub shared their version
of the subcommand, and this version integrates those changes.

This functionality is awesome -- thanks for pushing this forwards.

I feel the need to get some bike-shedding off my chest, though: "blame-tree" would be a terrible name for this command. I think that if Git ends up with two blame-like commands it will merely solidify Git's reputation for obscurity.

If this is really a form of blaming, then just make it an extension of "git blame", like maybe "git blame --latest".

Otherwise, please come up with a new command name. "git latest"? "git "latest-revs"? As long as it doesn't use the word "blame"...

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

		M.

[1] https://lore.kernel.org/git/20110302164031.GA18233@xxxxxxxxxxxxxxxxxxxxx/





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux